Re: GEQO vs join order restrictions

On Sun, Jul 19, 2009 at 1:23 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> 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_joinclause and have_join_order_restriction tests.
> This is obviously not material for this commitfest, though.  An
> important point is that we can't just throw memory at the problem,
> or we'll be giving up one of GEQO's advantages.
>
> 3. I think this puts the final nail in the coffin of the idea that
> we can get rid of the collapse_limits altogether.  I confess to having
> forgotten that one of their major functions was to bound memory usage in
> the regular planner, but this set of test runs adequately reminded me.
> I still think that we could look at revisiting their default values,
> but we'll probably want to fix GEQO per point 2 before we do any more
> testing.
>
> Barring objections, I'm going to mark the "remove collapse limits"
> patch as rejected.

Yeah, I think that's probably right. I still have some hope that we
will be able to get rid of these limits or dramatically raise them at
some point in the future, but it sounds like we have a good chunk of
work to do first. I really appreciate the testing that went into
finding and starting to fix these problems. Many thanks to both
Andres and Tom.

Tom, do you think the "independent subproblem" stuff from last night
would be worth pursuing? I haven't really looked at the code yet but
I would be willing to work on it when I have time; it would be useful
to have your thoughts on the approach before starting, though.

...Robert