On 25 January 2016 at 10:17, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <david.row...@2ndquadrant.com> writes: >> I've looked into why the join is not removed; since the redundant >> GROUP BY columns are removed during planning, and since the outer >> query is planned before the sub query, then when the join removal code >> checks if the subquery can been removed, the subquery is yet to be >> planned, so still contains the 2 GROUP BY items. > > Hmm ... but why did it get removed in the earlier patch version, then?
I'm not sure now, it was months ago. Perhaps I misremembered and only altered the test because I mistakenly anticipated it would break. >> Perhaps the useless columns can be removed a bit earlier, perhaps in >> parse analysis. I will look into that now. > > No; doing this in parse analysis will be sufficient reason to reject the > patch. That would mean adding a not-semantically-necessary dependency on > the pkey to a query when it is stored as a view. It has to be done at > planning time and no sooner. > > It's possible that you could integrate it into some earlier phase of > planning, like prepjointree, but I think that would be messy and likely > not worth it. I don't see any existing query-tree traversal this could > piggyback on, and I doubt we want to add a new pass just for this. It seems like a bit of a corner case anyway. Maybe it's fine as is. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
