Re: generic plans and "initial" pruning
Tender Wang <tndrwang@gmail.com>
Amit Langote <amitlangote09@gmail.com> 于2025年2月23日周日 16:36写道: > On Sun, Feb 23, 2025 at 2:03 AM Tender Wang <tndrwang@gmail.com> wrote: > > Alexander Lakhin <exclusion@gmail.com> 于2025年2月22日周六 23:00写道: > >> 21.02.2025 05:40, Amit Langote wrote: > >> > >> I pushed the final piece yesterday. > >> > >> > >> Please look at new error, produced by the following script, > >> starting from 525392d57: > >> CREATE TABLE t(id int) PARTITION BY RANGE (id); > >> CREATE INDEX idx on t(id); > >> CREATE TABLE tp_1 PARTITION OF t FOR VALUES FROM (10) TO (20); > >> CREATE TABLE tp_2 PARTITION OF t FOR VALUES FROM (20) TO (30) PARTITION > BY RANGE(id); > >> CREATE TABLE tp_2_1 PARTITION OF tp_2 FOR VALUES FROM (21) to (22); > >> CREATE TABLE tp_2_2 PARTITION OF tp_2 FOR VALUES FROM (22) to (23); > >> CREATE FUNCTION stable_one() RETURNS INT AS $$ BEGIN RETURN 1; END; $$ > LANGUAGE plpgsql STABLE; > >> > >> SELECT min(id) OVER (PARTITION BY id ORDER BY id) FROM t WHERE id >= > stable_one(); > >> > >> ERROR: XX000: trying to open a pruned relation > >> LOCATION: ExecGetRangeTableRelation, execUtils.c:830 > >> > >> This issue was discovered with SQLsmith. > > Thanks for the report. > > > The error message was added in commit 525392d57. In this case, the > estate->es_unpruned_relids only includes 1, which is the offset of table t. > > In register_partpruneinfo(), we collect glob->prunableRelids; in this > case, it contains 2,3,4,5. Then we will do: > > result->unprunableRelids = bms_difference(glob->allRelids, > > glob->prunableRelids); > > so the result->unprunableRelids only contains 1. > > > > But tp_2 is also partition table, and its partpruneinfo created by > create_append_plan() is put into the head of global list. > > So we first process it in ExecDoInitialPruning(). Then error reports > because we only contain 1 in estate->es_unpruned_relids. > > Thanks for checking. > > The RT index of tp_2 should appear in PlannedStmt.unprunableRelids, > because it needs to be opened in CreatePartitionPruneState() for > setting up its PartitionPruneInfo. We use ExecGetRangeTableRelation() > to open, which expects the relation to be locked, so the error. > > To ensure tp_2 appears in PlannedStmt.unprunableRelids, we should > prevent make_partitionedrel_pruneinfo() from placing the RT index into > leafpart_rti_map[], as the current condition for inclusion doesn’t > account for whether the partition is itself partitioned. > > I've come up with the attached. > LGTM. -- Thanks, Tender Wang
Commits
-
Stamp 19beta1.
- 4b0bf0788b06 19 (unreleased) cited
-
Revert "Don't lock partitions pruned by initial pruning"
- 1722d5eb05d8 18.0 landed
-
Ensure first ModifyTable rel initialized if all are pruned
- 28317de723b6 18.0 cited
-
Fix bug in cbc127917 to handle nested Append correctly
- cbb9086c9ef6 18.0 landed
-
Remove unstable test suite added by 525392d57
- 4f1b6e5bb4fe 18.0 landed
-
Don't lock partitions pruned by initial pruning
- 525392d5727f 18.0 landed
-
Fix an oversight in cbc127917 to handle MERGE correctly
- 75dfde13639a 18.0 landed
-
Track unpruned relids to avoid processing pruned relations
- cbc127917e04 18.0 landed
-
Perform runtime initial pruning outside ExecInitNode()
- d47cbf474ecb 18.0 landed
-
Move PartitionPruneInfo out of plan nodes into PlannedStmt
- bb3ec16e14de 18.0 landed
-
Fix setrefs.c's failure to do expression processing on prune steps.
- bf826ea06297 18.0 cited
-
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 landed
-
Revert "Move PartitionPruneInfo out of plan nodes into PlannedStmt"
- 5472743d9e85 16.0 landed
-
Move PartitioPruneInfo out of plan nodes into PlannedStmt
- ec386948948c 16.0 landed
-
Refactor and cleanup runtime partition prune code a little
- 297daa9d4353 15.0 landed
-
Remove some unnecessary fields from Plan trees.
- 52ed730d511b 12.0 cited
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 cited
-
Shut down Gather's children before shutting down Gather itself.
- acf555bc53ac 10.0 cited