Re: Removing Functionally Dependent GROUP BY Columns

David Rowley <david.rowley@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