Re: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id CAA4eK1K2=KL9x7UTAFQ-YgZX0xFHKQB3ayru-tcaqCAVmxS0wg@mail.gmail.com
Whole thread Raw
In response to RE: [Patch] Optimize dropping of relation buffers using dlist  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Responses RE: [Patch] Optimize dropping of relation buffers using dlist
List 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
by15 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
sharedbuffers 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.
Ifyou 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.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS
Next
From: vignesh C
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS