Keep no-match rows when pulling up a correlated aggregate subquery

[Alena0704]

With the Postgres planner (optimizer=off or an ORCA fallback), a correlated scalar subquery with an aggregate is pulled up into an INNER join with a grouped subquery (convert_EXPR_to_join), which drops outer rows that have no match. The original subquery keeps them: it computes the aggregate over empty input, so e.g. COUNT yields 0 there:

    select ... from t1
            where t1.a > (select count(*) from t2 where t2.a = t1.d);

A row with no match in t2 must be compared as "t1.a > 0" and can pass, but the INNER join dropped it.

To fix this, pull the subquery up into a LEFT join, so no-match rows survive as null-extended rows, and build the comparison above the join out of the aggregates the subquery exports:

outer OP expr(CASE WHEN match_flag THEN agg ELSE empty_input_value END)

match_flag is a constant TRUE column added to the subquery, so it is NULL exactly for the rows the LEFT join null-extended. For those the CASE yields what the aggregate returns over an empty input, and the expression around the aggregates then computes what the subquery would have returned.

The empty-input value comes from pg_aggregate: an aggregate with no final function returns its initial transition value (0 for count() and regr_count()), and one whose initial value is null returns NULL as long as its final function is strict (sum(), min(), max(), ...). For the rest -- avg() and friends, where the initial value is not null and only the final function knows that it turns into NULL -- the value cannot be derived, and the INNER join is kept as before.

Substituting the values into the expression and using that as a single ELSE branch is not enough: the result is a constant expression, and constant folding evaluates it while planning, so
"(select 10 / count(*) ...)" would fail with "division by zero" even though the query itself never divides by zero.

The comparison runs above the LEFT join as a filter, not as the join condition: as a join qual it would null-extend matched rows that fail it, and the empty-input value would let them back in.

The LEFT join is not always needed. If a no-match row cannot pass the comparison anyway -- "1 = (select count(*) ...)" turns into "1 = 0" for it -- dropping it is fine and the INNER join is kept as before. This is detected by substituting the empty-input value into the comparison and constant-folding it, which is only done where the folding cannot evaluate anything that would not be evaluated anyway. Ordinary sum/avg/min/max comparisons fall into this group: their empty-input value is NULL, and a comparison with NULL does not pass, so those plans do not change.

The pull-up bails out and the sublink runs as a SubPlan, as before, when the comparison cannot be placed above the join (the sublink is in an outer join's ON clause), when the subquery's targetlist is correlated, and when its expression contains

• a window function, which after the pull-up would run over all of the groups instead of over the single row an ungrouped aggregate produces for one outer row,

• an ordered-set or hypothetical-set aggregate, whose empty-input value does not follow from the transition machinery -- "rank(x) within group (order by y)" returns 1,

• an aggregate of the subquery inside a sub-select, which the rewrite above cannot reach.

Adapted from open-gpdb open-gpdb/gpdb#397 and Greengage GreengageDB/greengage#546.

Co-Authored-By: excaliiibur [excaliiibur@foxmail.com]