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

From Kyotaro Horiguchi
Subject Re: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id 20201022.151432.1287163027694697006.horikyota.ntt@gmail.com
Whole thread Raw
In response to RE: [Patch] Optimize dropping of relation buffers using dlist  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: [Patch] Optimize dropping of relation buffers using dlist
List pgsql-hackers
At Thu, 22 Oct 2020 01:33:31 +0000, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote in 
> From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> > The table below shows the vacuum execution time for non-recovery case.
> > I've also subtracted the execution time when VACUUM (truncate off) is set.
> > 
> > [NON-RECOVERY CASE - VACUUM execution Time in seconds]
> (snip)
> > | 100GB | 65.456 | 1.795   | -3546.57% |
> 
> So, the full shared buffer scan for 10,000 relations took about as long as 63 seconds (= 6.3 ms per relation).  It's
niceto shorten this long time.
 

I'm not sure about the exact steps of the test, but it can be expected
if we have many small relations to truncate.

Currently BUF_DROP_FULL_SCAN_THRESHOLD is set to Nbuffers / 512, which
is quite arbitrary that comes from a wild guess.

Perhaps we need to run benchmarks that drops one relation with several
different ratios between the number of buffers to-be-dropped and
Nbuffers, and preferably both on spinning rust and SSD.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Track statistics for streaming of in-progress transactions
Next
From: Dilip Kumar
Date:
Subject: Re: Track statistics for streaming of in-progress transactions