Hi,
Thanks for digging!
On 2016-01-16 11:23:31 +0000, Dean Rasheed wrote:
> When the clause is pushed down into the view it is turned from a WHERE
> clause into a HAVING clause, because the view query has grouping. That
> part is OK. However, the query planner then decides that since the new
> HAVING clause doesn't contain any aggregates or volatile expressions,
> it is safe to turn it back into a WHERE clause in the inner query.
> That would be OK for normal grouping, because in that case the clause
> would evaluate the same for all the rows in a group. However, that
> doesn't work for grouping sets, since the output of the grouping sets
> aggregation may contains nulls not present before grouping.
> Probably that change should be undone and the comment expanded to
> explain why it isn't safe when the query has grouping sets.
Hm, I'm a bit hesitant to potentially noticeably regress plans here,
although it seems unikely that already "relies" on this. Can't we
essentially treat references to columns which can be set to null by due
to a grouping set, as containing an agg clause and only prevent moving
in that case?
Greetings,
Andres Freund