| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: enable_joinremoval |
| Date: | 2010-03-29 15:46:55 |
| Message-ID: | 14201.1269877615@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-03-29 15:55:03 | Re: enable_joinremoval |
| Previous Message | Jaime Casanova | 2010-03-29 15:42:33 | Re: enable_joinremoval |