Hi, On Sun, Oct 12, 2026 shihao zhong wrote: > Eager aggregation can put a partial aggregate below a join whose > clause has a volatile function. The function then runs once per > group, not once per joined row.
I tested v1 against master with a differential that runs each query with eager aggregation on and off and counts the volatile function's evaluations (a sequence bump), requiring both the eval count and the result to match; a coverage guard checks that EXPLAIN really shows a partial aggregate. Over 23 placements of the volatile -- join ON, cross-rel WHERE, LEFT JOIN, 3-way joins (upper and lower), CASE, correlated subquery, LATERAL, semijoin, HAVING, plus partitionwise, parallel, window functions and an SRF in the target list -- master miscounts in every shape where the clause sits above the partial aggregate, and v1 fixes all of them. For the parallel ones I confirmed the plans really were parallel. It is not over-broad: where the volatile sits below the partial aggregate (3-way lower join, a WHERE on the grouped rel only, LATERAL, ...) v1 keeps eager aggregation and the count stays right, so it refuses eager aggregation only where it must. The positions I suspected statically (LATERAL, correlated subquery, semijoin, HAVING) were already correct on master. SQLancer (NoREC + TLP) on the v1 build ran clean, though it rarely generates a volatile join clause, so that is weak evidence here. Looks good to me. Regards, Manu
