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
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
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
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
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
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
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.
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