enable_joinremoval
in [PgSql]
|
From: Robert Haas on 29 Mar 2010 12:29 On Mon, Mar 29, 2010 at 12:17 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith <greg(a)2ndquadrant.com> wrote: >>> at the top of my list in this area for 9.1 is to track down the rumored >>> patch that exports information about the rejected plans considered and get >>> that comitted. That always seems what I want to look at for answering the >>> question "why this plan instead of what I was expecting?" > >> Having looked at that patch, I am skeptical of it, but we can >> certainly take a fresh look. > > The problem with this line of thought is that it imagines you can look > at worked-out alternative plans. You can't, because the planner doesn't > pursue rejected alternatives that far (and you'd not want to wait long > enough for it to do so...) Right. And that's not what the patch did. But a detailed discussion of this topic should be (a) conducted on a separate thread and (b) occur after we've all refamiliarized ourselves with it. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Smith on 29 Mar 2010 12:33 Tom Lane wrote: > The problem with this line of thought is that it imagines you can look > at worked-out alternative plans. You can't, because the planner doesn't > pursue rejected alternatives that far (and you'd not want to wait long > enough for it to do so...) > Not on any production system, sure. I know plenty of people who would gladly let a rejected plan enumerator run for *a day* on their development box if it let them figure out exactly why the costing on the plan they expected ended up higher than the plan they actually get. While I know you don't run into this, regular people can easily spend a week on one such problem without gaining even that much insight, given the current level of instrumentation and diagnostic tools available. "Read the source" and "ask Tom" are both effective ways to resolve that but have their limits. (Not because of you, of course--my bigger problem are people who just can't share their plans with the lists for privacy or security reasons) -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 29 Mar 2010 13:23 On Mon, 2010-03-29 at 11:27 -0400, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > And for the record, I believe I find it rather amusing that you're > > asking me if I "have the faintest idea how many there would be". > > Actually that was directed more at Simon. I think you should drop the personal comments. They have no place here. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 29 Mar 2010 13:26 On Mon, 2010-03-29 at 09:37 -0400, Robert Haas wrote: > In many > cases it's not horribly difficult to work around because you can do > SELECT * FROM ... instead of your original select list, but there > might be some cases with multiple levels of views where it isn't that > easy. I think it would be good to add this back. People have asked me how they would know whether join removal has worked. If there is a workaround that works for most cases, I think that might be all we need. Do you have an example where that doesn't work, so we can judge how common that would be? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 29 Mar 2010 14:17
On Mon, 2010-03-29 at 11:46 -0400, Tom Lane wrote: > Robert Haas <robertmhaas(a)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. You're not addressing the original point. I have been asked how would users know which tables have been removed and whether there is a way of checking that. That is not a request for a tuning feature, or something to reduce user confusion. If you don't like "enable_joinremoval" that's fine but it would be good to answer the original request with an alternative proposal. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |