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

From Robert Haas
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id E4896859-A214-4A14-89CC-EB2D175F8EF0@gmail.com
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: *_collapse_limit, geqo_threshold
List pgsql-hackers
On Jul 7, 2009, at 4:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
>> I guess my point is that there's not a lot of obvious benefit in
>> allowing the functionality to exist but handicapping it so that it's
>> useful in as few cases as possible.  If the consensus is that we want
>> half a feature (but not more or less than half), that's OK with me,
>> but it's not obvious to me why we should choose to want that.
>
> Well, the question to my mind is whether the collapse_threshold GUCs  
> in
> their current form actually represent a feature ;-).  They were put
> in pretty much entirely on speculation that someone might find them
> useful.  Your argument is that they are not only useless but a foot- 
> gun,
> and so far we haven't got any clear contrary evidence.  If we accept
> that argument then we should take them out, not just change the  
> default.
>
> 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.  But I'm fine with removing join_collapse_limit
> or reducing it to a boolean.

That's pretty much where I am with it, too.  The feature I was  
referring to was not the collapse limits, but the ability to  
explicitly specify the join order, which perhaps could be a useful  
tool for reducing planning time or coping with bad estimates if you  
could do it for only some of the joins in the query, but which we're  
instead proposing to keep as an all-or-nothing flag.

...Robert


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: WIP: Deferrable unique constraints
Next
From: Sergey Burladyan
Date:
Subject: Re: 8.4, One-Time Filter and subquery ( ... FROM function() union all ... )