Re: generic plans and "initial" pruning
Amit Langote <amitlangote09@gmail.com>
On Fri, Mar 11, 2022 at 11:35 PM Amit Langote <amitlangote09@gmail.com> wrote: > Attached is v5, now broken into 3 patches: > > 0001: Some refactoring of runtime pruning code > 0002: Add a plan_tree_walker > 0003: Teach AcquireExecutorLocks to skip locking pruned relations Repeated the performance tests described in the 1st email of this thread: HEAD: (copied from the 1st email) 32 tps = 20561.776403 (without initial connection time) 64 tps = 12553.131423 (without initial connection time) 128 tps = 13330.365696 (without initial connection time) 256 tps = 8605.723120 (without initial connection time) 512 tps = 4435.951139 (without initial connection time) 1024 tps = 2346.902973 (without initial connection time) 2048 tps = 1334.680971 (without initial connection time) Patched v1: (copied from the 1st email) 32 tps = 27554.156077 (without initial connection time) 64 tps = 27531.161310 (without initial connection time) 128 tps = 27138.305677 (without initial connection time) 256 tps = 25825.467724 (without initial connection time) 512 tps = 19864.386305 (without initial connection time) 1024 tps = 18742.668944 (without initial connection time) 2048 tps = 16312.412704 (without initial connection time) Patched v5: 32 tps = 28204.197738 (without initial connection time) 64 tps = 26795.385318 (without initial connection time) 128 tps = 26387.920550 (without initial connection time) 256 tps = 25601.141556 (without initial connection time) 512 tps = 19911.947502 (without initial connection time) 1024 tps = 20158.692952 (without initial connection time) 2048 tps = 16180.195463 (without initial connection time) Good to see that these rewrites haven't really hurt the numbers much, which makes sense because the rewrites have really been about putting the code in the right place. BTW, these are the numbers for the same benchmark repeated with plan_cache_mode = auto, which causes a custom plan to be chosen for every execution and so unaffected by this patch. 32 tps = 13359.225082 (without initial connection time) 64 tps = 15760.533280 (without initial connection time) 128 tps = 15825.734482 (without initial connection time) 256 tps = 15017.693905 (without initial connection time) 512 tps = 13479.973395 (without initial connection time) 1024 tps = 13200.444397 (without initial connection time) 2048 tps = 12884.645475 (without initial connection time) Comparing them to numbers when using force_generic_plan shows that making the generic plans faster is indeed worthwhile. -- Amit Langote EDB: http://www.enterprisedb.com
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