Re: BUG #19649: Qual pushdown into GROUP BY subqueries ignores non-equivalence-preserving references to grouping col

сб, 5 сент. 2026 г. в 12:52, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>:

> v3 in attachment.
>
> P.S. I'm still learning plans and could be mistaken, so please don't judge
> too harshly.
>

I looked more carefully at how the pushed qual is placed, and I had
misread the plan when I wrote v3. For a GROUP BY subquery the wrapped
qual is not pushed below the grouping. subquery_push_qual attaches it to
HAVING, and find_having_conflicts then keeps it there through the same
walker that the clauses.c fix changes. So v2 already produced correct
results for GROUP BY, by construction rather than by accident.
```
if (subquery->hasAggs || subquery->groupClause ||
subquery->groupingSets || subquery->havingQual)
subquery->havingQual = make_and_qual(subquery->havingQual, qual);
else
subquery->jointree->quals = make_and_qual(...);
```
So a wrapped jsonb qual such as j::text = '1' stays in HAVING and is not
lowered to WHERE. That is why the GroupAggregate and HashAggregate cases
already gave correct results under v2, with the filter on the Agg node.
DISTINCT, window PARTITION BY and set operations are different. They have
no HAVING, so subquery_push_qual routes the pushed qual to WHERE. That is
why point 6 in qual_is_pushdown_safe lists those three and omits GROUP BY.
The clauses.c fix covers both boundaries because both share the walker.
So the groupClause check I added to qual_is_pushdown_safe in v3 is
redundant for correctness. It only changes the plan shape: the filter
ends up on the Subquery Scan instead of on the Agg node. Both are
correct.

I attach v4, it is v2 with fixed comment.
Sorry for the noise, I'll be more attentive and take my time.