On Tue, Jul 7, 2009 at 6:33 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Jul 7, 2009, at 4:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> My own thought is that from_collapse_limit has more justification,
>
>> 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.
>
> It's pretty much all-or-nothing now: the GUC does not give you any sort
> of useful control over *which* joins are reorderable.
Yes. So the way I see it, the options are:
1. We can remove join_collapse_limit completely and provide no
substitute. In this case, the ability to explicitly specify the join
order will be gone.
2. We can remove join_collapse_limit but provide a different, Boolean
GUC instead, like enable_join_reordering. In this case, we're not
actually reducing the number of GUCs, just the size of the foot-gun.
3. We can remove join_collapse_limit and provide an alternative way to
explicitly specify the join order that is more flexible. This both
reduces the number of GUCs and arguably provides some useful
functionality that we don't have now.
It sounds like your vote is for #2, which, as I say, seems like a
feature with one arm tied behind its back, but hey, what do I know?
Accepting that as the consensus in the absence of contrary votes, we
still need to decide what to do about from_collapse_threshold and
geqo_threshold. I'm pretty sure that we shouldn't eliminate GEQO or
geqo_threshold, because the basic algorithm is clearly exponential
time and eventually you have to start worrying about that, but we
could raise the value. What to do about from_collapse_threshold is
less clear to me.
...Robert