Andres Freund <andres@anarazel.de> writes:
> On Thursday 16 July 2009 15:13:02 Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> "Error: Failed to make a valid plan"
>> We're not going to be able to fix this unless you show us examples.
> In the other thread I attached a similar to the real schema + example query.
> Not enough? And why?
I tried the example query and couldn't get "Failed to make a valid plan"
out of it ... what settings do you need for that?
However, I do observe that this seems a sufficient counterexample
against the theory that we can just remove the collapse limits and let
GEQO save us on very complex queries. On my machine, the example query
takes about 22 seconds to plan using CVS HEAD w/ all default settings.
If I set both collapse_limit variables to very high values (I used 999),
it takes ... um ... not sure; I gave up waiting after half an hour.
I also tried with geqo_effort reduced to the minimum of 1, but that
didn't produce a plan in reasonable time either (I gave up after ten
minutes). So if we remove the collapse limits, Postgres will completely
fail on this query --- the only way out would be enable_join_ordering =
off, which is hardly likely to produce a decent plan.
Maybe we should leave the collapse_limit logic alone and address
Robert's gripes by just raising the default values a lot (I'm thinking
100 or so). That way there's an escape hatch for anyone who has
pathological queries to deal with --- just dial the settings down.
>>> Noticeable even some plans which were plannable in reasonable time before
>>> now are problematic with enable_join_ordering=false!
>> And this even more so --- it doesn't make any sense at all.
> Why? With a high from_collapse_limit more subqueries get inlined - before
> inlining they get planned separately.
Okay, I misunderstood which two cases you were comparing there.
regards, tom lane