On Wed, May 27, 2026 at 8:04 AM Richard Guo <[email protected]> wrote: > Thanks for raising these points. For partition pruning, > match_clause_to_partition_key() already checks both collation and > opfamily compatibility, so I don't think it has similar issues. I'm > not sure what is meant by "window function pushdowns", but your > question prompted me to look around, and I did notice that pushing > restriction clauses down into a subquery suffers from a similar > problem, specifically, when the subquery has DISTINCT, DISTINCT ON, or > a window PARTITION BY clause.
I think all these issues belong to the same class of bug: the planner moves a qual clause across a grouping layer, and the result is wrong when the qual's equivalence relation disagrees with the grouping's, either an opfamily mismatch or a nondeterministic-collation mismatch. This includes HAVING-to-WHERE pushdown, as well as qual pushdown into a subquery past its DISTINCT, DISTINCT ON, window PARTITION BY, or set-operation grouping layer. v2 attached tries to fix the full bug class through a shared walker expression_has_grouping_conflict that detects either kind of conflict in an expression tree. The walker takes a callback that maps each Var to the grouping equality operator for its column (or InvalidOid for non-grouping Vars). See the commit message for details. - Richard
v2-0001-Fix-qual-pushdown-past-grouping-with-mismatched-e.patch
Description: Binary data
