pgsql: Further adjust EXPLAIN's choices of table alias names. - Mailing list pgsql-committers
| From | Tom Lane |
|---|---|
| Subject | pgsql: Further adjust EXPLAIN's choices of table alias names. |
| Date | |
| Msg-id | E1ifA74-0001ld-CO@gemulon.postgresql.org Whole thread Raw |
| List | pgsql-committers |
Further adjust EXPLAIN's choices of table alias names. This patch causes EXPLAIN to always assign a separate table alias to the parent RTE of an append relation (inheritance set); before, such RTEs were ignored if not actually scanned by the plan. Since the child RTEs now always have that same alias to start with (cf. commit 55a1954da), the net effect is that the parent RTE usually gets the alias used or implied by the query text, and the children all get that alias with "_N" appended. (The exception to "usually" is if there are duplicate aliases in different subtrees of the original query; then some of those original RTEs will also have "_N" appended.) This results in more uniform output for partitioned-table plans than we had before: the partitioned table itself gets the original alias, and all child tables have aliases with "_N", rather than the previous behavior where one of the children would get an alias without "_N". The reason for giving the parent RTE an alias, even if it isn't scanned by the plan, is that we now use the parent's alias to qualify Vars that refer to an appendrel output column and appear above the Append or MergeAppend that computes the appendrel. But below the append, Vars refer to some one of the child relations, and are displayed that way. This seems clearer than the old behavior where a Var that could carry values from any child relation was displayed as if it referred to only one of them. While at it, change ruleutils.c so that the code paths used by EXPLAIN deal in Plan trees not PlanState trees. This effectively reverts a decision made in commit 1cc29fe7c, which seemed like a good idea at the time to make ruleutils.c consistent with explain.c. However, it's problematic because we'd really like to allow executor startup pruning to remove all the children of an append node when possible, leaving no child PlanState to resolve Vars against. (That's not done here, but will be in the next patch.) This requires different handling of subplans and initplans than before, but is otherwise a pretty straightforward change. Discussion: https://postgr.es/m/001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6ef77cf46e81f45716ec981cb08781d426181378 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 90 +- src/backend/commands/explain.c | 65 +- src/backend/executor/execParallel.c | 2 + src/backend/executor/nodeModifyTable.c | 3 - src/backend/nodes/copyfuncs.c | 3 + src/backend/nodes/outfuncs.c | 4 + src/backend/nodes/readfuncs.c | 3 + src/backend/optimizer/plan/createplan.c | 2 + src/backend/optimizer/plan/planner.c | 10 +- src/backend/optimizer/plan/setrefs.c | 71 +- src/backend/utils/adt/ruleutils.c | 410 ++++--- src/include/nodes/execnodes.h | 1 - src/include/nodes/pathnodes.h | 2 + src/include/nodes/plannodes.h | 4 + src/include/utils/ruleutils.h | 10 +- src/test/regress/expected/aggregates.out | 48 +- src/test/regress/expected/alter_table.out | 26 +- src/test/regress/expected/inherit.out | 340 +++--- src/test/regress/expected/join.out | 12 +- src/test/regress/expected/partition_aggregate.out | 150 +-- src/test/regress/expected/partition_join.out | 940 ++++++++-------- src/test/regress/expected/partition_prune.out | 1234 ++++++++++----------- src/test/regress/expected/rowsecurity.out | 126 +-- src/test/regress/expected/select_parallel.out | 56 +- src/test/regress/expected/tablesample.out | 16 +- src/test/regress/expected/updatable_views.out | 40 +- 26 files changed, 1936 insertions(+), 1732 deletions(-)
pgsql-committers by date: