Re: [Patch] Optimize dropping of relation buffers using dlist

At Thu, 22 Oct 2020 01:33:31 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
> From: Jamison, Kirk/ジャミソン カーク <k(dot)jamison(at)fujitsu(dot)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 nice to 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