forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commita929e17
committed
Allow run-time pruning on nested Append/MergeAppend nodes
Previously we only tagged on the required information to allow theexecutor to perform run-time partition pruning for Append/MergeAppendnodes belonging to base relations. It was thought that nestedAppend/MergeAppend nodes were just about always pulled up into thetop-level Append/MergeAppend and that making the run-time pruning info forany sub Append/MergeAppend nodes was a waste of time. However, that waslikely badly thought through.Some examples of cases we're unable to pullup nested Append/MergeAppendsare: 1) Parallel Append nodes with a mix of parallel and non-parallelpaths into a Parallel Append. 2) When planning an ordered Append scan asub-partition which is unordered may require a nested MergeAppend path toensure sub-partitions don't mix up the order of tuples being fed into thetop-level Append.Unfortunately, it was not just as simple as removing the lines increateplan.c which were purposefully not building the run-time pruninginfo for anything but RELOPT_BASEREL relations. The code inadd_paths_to_append_rel() was far too sloppy about which partitioned_relsit included for the Append/MergeAppend paths. The original code therewould always assume accumulate_append_subpath() would pull each sub-Appendand sub-MergeAppend path into the top-level path. While it does notappear that there were any actual bugs caused by having the additionalpartitioned table RT indexes recorded, what it did mean is that later inplanning, when we built the run-time pruning info that we wasted effortand built PartitionedRelPruneInfos for partitioned tables that we had nosubpaths for the executor to run-time prune.Here we tighten that up so that partitioned_rels only ever contains the RTindex for partitioned tables which actually have subpaths in the givenAppend/MergeAppend. We can now Assert that every PartitionedRelPruneInfohas a non-empty present_parts. That should allow us to catch any weirdcorner cases that have been missed.In passing, it seems there is no longer a good reason to have theAppendPath and MergeAppendPath's partitioned_rel fields a List of IntList.We can simply have a List of Relids instead. This is more compact inmemory and faster to add new members to. We still know which is the rootlevel partition as these always have a lower relid than their children.Previously this field was used for more things, but run-time partitionpruning now remains the only user of it and it has no need for a List ofIntLists.Here we also get rid of the RelOptInfo partitioned_child_rels field. Thisis what was previously used to (sometimes incorrectly) set theAppend/MergeAppend path's partitioned_rels field. That was the only usageof that field, so we can happily just remove it.I also couldn't resist changing some nearby code to make use of the newlyadded for_each_from macro so we can skip the first element in the listwithout checking if the current item was the first one on eachiteration.A bug report from Andreas Kretschmer prompted all this work, however,after some consideration, I'm not personally classing this as a bug fix.So no backpatch. In Andreas' test case, it just wasn't that clear thatthere was a nested Append since the top-level Append just had a singlesub-path which was pulled up a level, per8edd0e7.Author: David RowleyReviewed-by: Amit LangoteDiscussion:https://postgr.es/m/flat/CAApHDvqSchs%2BubdybcfFaSPB%2B%2BEA7kqMaoqajtP0GtZvzOOR3g%40mail.gmail.com1 parentdfc7977 commita929e17
File tree
8 files changed
+319
-115
lines changed- src
- backend
- nodes
- optimizer
- path
- plan
- util
- partitioning
- include/nodes
- test/regress
- expected
- sql
8 files changed
+319
-115
lines changedLines changed: 0 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2310 | 2310 | | |
2311 | 2311 | | |
2312 | 2312 | | |
2313 | | - | |
2314 | 2313 | | |
2315 | 2314 | | |
2316 | 2315 | | |
| |||
0 commit comments
Comments
(0)