Re: *_collapse_limit, geqo_threshold

On Jul 7, 2009, at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
>> One possibility would be to remove join_collapse_limit entirely, but
>> that would eliminate one possibily-useful piece of functionality that
>> it current enables: namely, the ability to exactly specify the join
>> order by setting join_collapse_limit to 1.  So one possibility would
>> be to rename the variable something like explicit_join_order and make
>> it a Boolean; another possibility would be to change the default  
>> value
>> to INT_MAX.
>
> As the person who put in those thresholds, I kind of prefer going over
> to the boolean definition.

I'm OK with that, but out of conservatism suggested changing the  
default to unlimited in this release.  If by chance there is something  
we're missing and these parameters are doing someone any good, we can  
suggest that they set them back to the old values rather than telling  
them to use a private build.  If on the other hand we don't get any  
complaints, we can remove them with greater confidence in a future  
release.  But maybe that's too conservative.

Now, here's another thought: if we think it's reasonable for people to  
want to explicitly specify the join order, a GUC isn't really the best  
fit, because it's all or nothing.  Maybe we'd be better off dropping  
the GUCs entirely and adding some other bit of syntax that forces the  
join order, but only for that particular join.

> That was the alternative that we considered;
> the numeric thresholds were used instead because they were easy to
> implement and seemed to possibly offer more control.  But I'm not
> convinced that anyone has really used them profitably.  I agree that
> the ability to use JOIN syntax to specify the join order exactly (with
> join_collapse_limit=1) is the only really solid use-case anyone has
> proposed for either threshold.  I'm interested in Andreas' comment  
> that
> he has use-cases where using the collapse_limit is better than  
> allowing
> geqo to take over for very large problems ... but I think we need to  
> see
> those use-cases and see if there's a better fix.
>
>            regards, tom lane

Agreed.

...Robert