Re: *_collapse_limit, geqo_threshold

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

> Robert Haas <robertmhaas(at)gmail(dot)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