Re: *_collapse_limit, geqo_threshold - Mailing list pgsql-hackers

From Tom Lane
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 29789.1247004913@sss.pgh.pa.us
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane escribi�:
>> My own thought is that from_collapse_limit has more justification,
>> since it basically acts to stop a subquery from being flattened when
>> that would make the parent query too complex, and that seems like a
>> more understandable and justifiable behavior than treating JOIN
>> syntax specially.

> Isn't that what we use OFFSET 0 for?  That one has also the nice
> property that you can actually specify which subquery you want to
> prevent from being flattened.

Well, if you want to modify your queries to prevent long planning times,
that'd be one way to do it.  It doesn't seem like a generally useful
answer to me though.  For example, typically the subquery would actually
be a view that might be used in various contexts.  If you stick an
OFFSET in it then you disable flattening in all those contexts, likely
not the best answer.

> Personally I have never seen a case where the collapse_limits were
> useful tools.

I'm not convinced they're useful either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: 8.4, One-Time Filter and subquery ( ... FROM function() union all ... )
Next
From: Tom Lane
Date:
Subject: Re: 8.4, One-Time Filter and subquery ( ... FROM function() union all ... )