On 07/10/17 18:15, Tom Lane wrote: > Petr Jelinek <petr.jeli...@2ndquadrant.com> writes: >> On 07/10/17 04:19, Tom Lane wrote: >>> (edit: a few minutes later, I seem to remember that equivclass.c has >>> to do something special with the X=X case, so maybe it could do >>> something else special instead, with little new overhead.) > >> So I wrote prototype of achieving this optimization and it seems to be >> really quite simple code-wise (see attached). I did only a limited >> manual testing of this but I don't see any negative impact on planning time. > > No, I'm afraid you didn't read that comment closely enough. This will > flat out fail for cases like "select ... where x=x order by x", because > there will already be a single-element EC for x and so the clause will > just disappear entirely. If that doesn't happen, then instead you're > creating an EC with duplicate entries, which is an idea I seriously > dislike; the semantics of that don't seem clear at all to me.
Hmm it did not disappear (and worked fine in SQL level tests). I don't think I fully understand the "EC with duplicate entries" part and what's the problem with it so I'll defer to your wisdom there. > What I was imagining was that having detected X=X, instead of "throwing > back" the clause as-is we could throw back an X IS NOT NULL clause, > along the lines of the attached. Right, I wanted to avoid messing with the incoming result info, but if we don't want to call the code bellow or write tons of code for this, I guess it's the best we can do. > This passes the smell test for me in the sense of not adding any > significant number of planner cycles except when the weird case occurs. > It leaves something on the table in that there are some situations > where X=X could be converted, but we won't do it because we don't see > the clause as being a potential EC (because it's not at top level), > as in the second new regression test case below. I think that's > probably all right; I don't see any way to be more thorough without > adding a lot of new cycles all the time, and I don't believe this is > worth that. > My code had same issue. I think going deeper would require quite a bit of new code (and cycles) for something that's even less likely to happen than simple X=X while the current patch is quite cheap win. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers