pgsql: Introduce an RTE for the grouping step - Mailing list pgsql-committers

Introduce an RTE for the grouping step

If there are subqueries in the grouping expressions, each of these
subqueries in the targetlist and HAVING clause is expanded into
distinct SubPlan nodes.  As a result, only one of these SubPlan nodes
would be converted to reference to the grouping key column output by
the Agg node; others would have to get evaluated afresh.  This is not
efficient, and with grouping sets this can cause wrong results issues
in cases where they should go to NULL because they are from the wrong
grouping set.  Furthermore, during re-evaluation, these SubPlan nodes
might use nulled column values from grouping sets, which is not
correct.

This issue is not limited to subqueries.  For other types of
expressions that are part of grouping items, if they are transformed
into another form during preprocessing, they may fail to match lower
target items.  This can also lead to wrong results with grouping sets.

To fix this issue, we introduce a new kind of RTE representing the
output of the grouping step, with columns that are the Vars or
expressions being grouped on.  In the parser, we replace the grouping
expressions in the targetlist and HAVING clause with Vars referencing
this new RTE, so that the output of the parser directly expresses the
semantic requirement that the grouping expressions be gotten from the
grouping output rather than computed some other way.  In the planner,
we first preprocess all the columns of this new RTE and then replace
any Vars in the targetlist and HAVING clause that reference this new
RTE with the underlying grouping expressions, so that we will have
only one instance of a SubPlan node for each subquery contained in the
grouping expressions.

Bump catversion because this changes the querytree produced by the
parser.

Thanks to Tom Lane for the idea to invent a new kind of RTE.

Per reports from Geoff Winkless, Tobias Wendorff, Richard Guo from
various threads.

Author: Richard Guo
Reviewed-by: Ashutosh Bapat, Sutou Kouhei
Discussion: https://postgr.es/m/CAMbWs4_dp7e7oTwaiZeBX8+P1rXw4ThkZxh1QG81rhu9Z47VsQ@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/247dea89f7616fdf06b7272b74abafc29e8e5860

Modified Files
--------------
src/backend/commands/explain.c             |  24 +++-
src/backend/nodes/nodeFuncs.c              |  14 ++
src/backend/nodes/outfuncs.c               |   3 +
src/backend/nodes/print.c                  |   4 +
src/backend/nodes/readfuncs.c              |   3 +
src/backend/optimizer/path/allpaths.c      |   4 +
src/backend/optimizer/plan/planner.c       |  70 ++++++++--
src/backend/optimizer/plan/setrefs.c       |   1 +
src/backend/optimizer/prep/prepjointree.c  |   9 +-
src/backend/optimizer/util/var.c           | 138 +++++++++++++++++++
src/backend/parser/parse_agg.c             | 214 ++++++++++++++++++++---------
src/backend/parser/parse_relation.c        |  79 ++++++++++-
src/backend/parser/parse_target.c          |   9 ++
src/backend/utils/adt/ruleutils.c          |  27 +++-
src/include/catalog/catversion.h           |   2 +-
src/include/commands/explain.h             |   2 +
src/include/nodes/nodeFuncs.h              |   2 +
src/include/nodes/parsenodes.h             |   9 ++
src/include/nodes/pathnodes.h              |   6 +
src/include/optimizer/optimizer.h          |   1 +
src/include/parser/parse_node.h            |   3 +
src/include/parser/parse_relation.h        |   2 +
src/test/regress/expected/groupingsets.out | 138 +++++++++++++++++++
src/test/regress/sql/groupingsets.sql      |  51 +++++++
src/tools/pgindent/typedefs.list           |   2 +-
25 files changed, 731 insertions(+), 86 deletions(-)