Re: Hybrid Hash/Nested Loop joins and caching results from subplans
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Andy Fan <zhihui.fan1213@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-02T20:54:41Z
Lists: pgsql-hackers
On Tue, 2 Jun 2020 at 21:05, Andy Fan <zhihui.fan1213@gmail.com> wrote: > Today I tested the correctness & performance of this patch based on TPC-H > workload, the environment is setup based on [1]. Correctness is tested by > storing the result into another table when this feature is not introduced and > then enable this feature and comparing the result with the original ones. No > issue is found at this stage. Thank you for testing it out. > I also checked the performance gain for TPC-H workload, totally 4 out of the 22 > queries uses this new path, 3 of them are subplan, 1 of them is nestloop. All of > changes gets a better result. You can check the attachments for reference. > normal.log is the data without this feature, patched.log is the data with the > feature. The data doesn't show the 10x performance gain, I think that's mainly > data size related. Thanks for running those tests. I had a quick look at the results and I think to say that all 4 are better is not quite right. One is actually a tiny bit slower and one is only faster due to a plan change. Here's my full analysis. Q2 uses a result cache for the subplan and has about a 37.5% hit ratio which reduces the execution time of the query down to 67% of the original. Q17 uses a result cache for the subplan and has about a 96.5% hit ratio which reduces the execution time of the query down to 24% of the original time. Q18 uses a result cache for 2 x nested loop joins and has a 0% hit ratio. The execution time is reduced to 91% of the original time only because the planner uses a different plan, which just happens to be faster by chance. Q20 uses a result cache for the subplan and has a 0% hit ratio. The execution time is 100.27% of the original time. There are 8620 cache misses. All other queries use the same plan with and without the patch. > At the code level, I mainly checked nestloop path and cost_resultcache_rescan, > everything looks good to me. I'd like to check the other parts in the following days. Great. > [1] https://ankane.org/tpc-h
Commits
-
Add Result Cache executor node (take 2)
- 9eacee2e62d8 14.0 landed
-
Add Result Cache executor node
- b6002a796dc0 14.0 landed
-
Allow estimate_num_groups() to pass back further details about the estimation
- ed934d4fa30f 14.0 landed
-
Allow users of simplehash.h to perform direct deletions
- ff53d7b159b9 14.0 landed
-
Cache if PathTarget and RestrictInfos contain volatile functions
- f58b230ed0db 14.0 landed
-
Fix pull_varnos' miscomputation of relids set for a PlaceHolderVar.
- 55dc86eca70b 14.0 cited