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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
