Add child_append_relid_sets to ElidedNode; use in pg_plan_advice. Commit 0d4391b265f83023d0b7eed71817517410f76e60 taught the planner to store information about the RTIs of SubqueryScan, Append, and MergeAppend node elided from the plan using a new ElidedNode data structure; an hour later, 7358abcc6076f4b2530d10126ab379f8aea612a5 taught to save the RTIs of an Append node into another Append node using a new child_append_relid_sets field. Regrettably, despite the fact that both commits were written by me and the fact that both were part of the same patch set, the latter commit failed to deal with the case where an Append node first acquires child_append_relid_sets != NIL and then gets elided. I believe that I thought that was impossible, but the included test case shows that it isn't.
The proper fix involves updating the definition of ElidedNode to carry child_append_relid_sets, so this commit does that, breaking ABI compatibility. That's fine for the master branch, but it's a bit unfortunate to be doing do that so close to the planned ship date for v19. However, shipping v19 without fixing this appears (at least to me) to be even more unfortunate. Backpatch-through: 19 Discussion: http://postgr.es/m/ca+tgmoyyhc4i-gpzc9-jyhqih6pok+6ltyfinr-pioxg1nk...@mail.gmail.com Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/80db5ca9ece768e45321ca8fb88e2a9e67f8dcb5 Modified Files -------------- contrib/pg_overexplain/expected/pg_overexplain.out | 9 ++++++--- contrib/pg_overexplain/pg_overexplain.c | 3 +++ contrib/pg_plan_advice/expected/partitionwise.out | 13 +++++++++++++ contrib/pg_plan_advice/pgpa_scan.c | 3 +++ contrib/pg_plan_advice/sql/partitionwise.sql | 4 ++++ src/backend/optimizer/plan/setrefs.c | 18 +++++++++++++----- src/include/nodes/plannodes.h | 4 ++++ 7 files changed, 46 insertions(+), 8 deletions(-)
