On 25 January 2016 at 10:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
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
