Re: [Patch] Optimize dropping of relation buffers using dlist
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@fujitsu.com>, "Jamison,
Kirk" <k.jamison@fujitsu.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-30T11:58:16Z
Lists: pgsql-hackers
On Wed, Dec 30, 2020 at 11:28 AM Tang, Haiying <tanghy.fnst@cn.fujitsu.com> wrote: > > Hi Amit, > > In last mail(https://www.postgresql.org/message-id/66851e198f6b41eda59e6257182564b6%40G08CNEXMBPEKD05.g08.fujitsu.local), > I've sent you the performance test results(run only 1 time) on single table. Here is my the retested results(average by 15 times) which I think is more accurate. > > In terms of 20G and 100G, the optimization on 100G is linear, but 20G is nonlinear(also include test results on shared buffers of 50G/60G), so it's a little difficult to decide the threshold from the two for me. > If just consider 100G, I think NBuffers/32 is the optimized max relation size. But I don't know how to judge for 20G. If you have any suggestion, kindly let me know. > Considering these results NBuffers/64 seems a good threshold as beyond that there is no big advantage. BTW, it is not clear why the advantage for single table is not as big as multiple tables with the Truncate command. Can you share your exact test steps for any one of the tests? Also, did you change autovacumm = off for these tests, if not then the results might not be reliable because before you run the test via Vacuum command autovacuum would have done that work? -- With Regards, Amit Kapila.
Commits
-
Fix size overflow in calculation introduced by commits d6ad34f3 and bea449c6.
- 519e4c9ee21a 14.0 landed
-
Optimize DropRelFileNodesAllBuffers() for recovery.
- bea449c635c0 14.0 landed
-
Optimize DropRelFileNodeBuffers() for recovery.
- d6ad34f3410f 14.0 landed
-
Cache smgrnblocks() results in recovery.
- c5315f4f4484 14.0 cited
-
Add a check to prevent overwriting valid data if smgrnblocks() gives a
- ffae5cc5a602 8.2.0 cited