Re: [HACKERS] GEQO vs join order restrictions

2009-08-08 Thread Robert Haas
On Sun, Jul 19, 2009 at 3:08 PM, Tom Lane wrote: > Robert Haas writes: >> Tom, do you think the "independent subproblem" stuff from last night >> would be worth pursuing? > > It's worth looking into.  I'm not certain if it will end up being a good > idea or not.  Right now the joinlist collapse co

Re: [HACKERS] GEQO vs join order restrictions

2009-07-22 Thread Andres Freund
Hi Tom, Robert, Hi all, nks, On Sunday 19 July 2009 19:23:18 Tom Lane wrote: > Andres Freund writes: > > On Saturday 18 July 2009 17:48:14 Tom Lane wrote: > >> I'm inclined to address this by rewriting gimme_tree so that it *always* > >> finds a valid join order based on the given tour. This woul

Re: [HACKERS] GEQO vs join order restrictions

2009-07-19 Thread Tom Lane
Robert Haas writes: > Tom, do you think the "independent subproblem" stuff from last night > would be worth pursuing? It's worth looking into. I'm not certain if it will end up being a good idea or not. Right now the joinlist collapse code is pretty stupid (as you know --- it only thinks about

Re: [HACKERS] GEQO vs join order restrictions

2009-07-19 Thread Robert Haas
On Sun, Jul 19, 2009 at 1:23 PM, Tom Lane wrote: > My conclusions are: > > 1.  I should clean up and apply the attached patch.  Even though it's > not the whole answer, it clearly makes things a good deal better. > > 2. We need to look into a more efficient representation for making > have_relevant

Re: [HACKERS] GEQO vs join order restrictions

2009-07-19 Thread Tom Lane
Andres Freund writes: > On Saturday 18 July 2009 17:48:14 Tom Lane wrote: >> I'm inclined to address this by rewriting gimme_tree so that it *always* >> finds a valid join order based on the given tour. This would involve >> searching the whole stack for a possible join partner instead of >> cons

Re: [HACKERS] GEQO vs join order restrictions

2009-07-18 Thread Robert Haas
On Sat, Jul 18, 2009 at 12:49 PM, Tom Lane wrote: > We could refrain from collapsing the sub-problem during joinlist > formation.  But the trouble with that is it creates a "hard" join order > restriction.  Most of the restrictions are "soft" to some extent, ie, > you can do some rearrangements but

Re: [HACKERS] GEQO vs join order restrictions

2009-07-18 Thread Tom Lane
Andres Freund writes: > This also explains why I saw nearly no improvement during the genetic search > itself. The paths out of random_init_pool were already hugely selected, so > there were not that many improvements to find and a change was relatively > like > to yield a impossible ordering.

Re: [HACKERS] GEQO vs join order restrictions

2009-07-18 Thread Andres Freund
On Saturday 18 July 2009 17:48:14 Tom Lane wrote: > I spent a bit of time looking into why GEQO behaves so miserably on the > test case Andres Freund presented here: > http://archives.postgresql.org/message-id/200907091700.43411.and...@anaraze >l.de > > The difficulty seems to be that the problem q