Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-04T09:54:37Z
Lists: pgsql-hackers
On Tue, 4 Nov 2025 at 21:00, Alexander Lakhin <exclusion@gmail.com> wrote: > Please look at a new anomaly, introduced with 03d40e4b5: > CREATE TABLE t(i integer); > CREATE TABLE pt(i integer) PARTITION BY LIST(i); > > SET enable_seqscan = 'off'; > SELECT * FROM t UNION SELECT * FROM t > UNION ALL > SELECT * FROM pt; > produces: > ERROR: XX000: unrecognized node type: 0 Thanks for the report. This seems to be due to the fact that the same UPPERREL_SETOP RelOptInfo is being used for the UNION and UNION ALL. When doing the add_path() for the UNION ALL at prepunion.c:1030, the sole child path of the Append being added is an AggPath for the previous UNION operation. When we add_path() the AppendPath, the previous AggPath is already in the pathlist of the result_rel. add_path() ends up freeing the old Path due to the new AppendPath being better and the end result is the Append's subpath is free'd. The reason we end up with the same result_rel is that we're not passing all the relids in fetch_upper_rel(root, UPPERREL_SETOP, relids) due to having removed dummy rels. I guess the fix might be something like record the relids even when skipping dummy relations. I'll go and explore that as an option. David
Commits
-
Fix UNION planner estimate_num_groups with varno==0
- eaa159632d03 19 (unreleased) landed
-
Fix possible usage of incorrect UPPERREL_SETOP RelOptInfo
- fdda78e361f1 19 (unreleased) landed
-
Teach planner to short-circuit EXCEPT/INTERSECT with dummy inputs
- 9c9d41af4db7 19 (unreleased) landed
-
Fix incorrect targetlist in dummy UNIONs
- 928df067d1e6 19 (unreleased) landed
-
Teach UNION planner to remove dummy inputs
- 03d40e4b523b 19 (unreleased) landed