On Mon, Mar 29, 2010 at 11:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> OK, I'll write a patch for that; and a consensus emerges that we
>> should also have enable_joinremoval, then I will add that as well. I
>> think the only argument for NOT having enable_joinremoval is that you
>> can always modify the query to say SELECT * rather than some more
>> specific SELECT list,
>
> Uh, no, the argument for not having enable_joinremoval is that it's
> useless.
>
> In particular, I categorically deny the argument that putting it in will
> reduce user confusion. If anyone is confused because EXPLAIN shows that
> some table isn't getting joined to, you think that the fact that
> somewhere in the manual is a mention of enable_joinremoval will
> un-confuse them? If they knew that switch was there or what it did,
> they wouldn't be confused to begin with.
Uh, wow, no, it doesn't make any sense from that point of view. What
I think the use case is is seeing how join removal changed the plan.
It could work out that the plan WITH join removal is significantly
different from the plan WITHOUT join removal. Most of the time that
won't be the case - the join will just get snipped out. But suppose
we're joining A to B and then to C and then to D, and that's the
actual join order. Suppose further that C is most cheaply done as a
hash join. It seems just barely possible to think that if the join to
C actually doesn't need to be done at all, then the join to D might be
done via some other method, because with the disappearance of the join
to C the join to D will receive its left input in some kind of sorted
order.
...Robert