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? > 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. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers