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 CAA4eK1+9sn7Qx4ne+GJUQZSJK56JKjVBSKx-nNS+H2GnS0XZ2g@mail.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
RE: [Patch] Optimize dropping of relation buffers using dlist
List pgsql-hackers
On Thu, Oct 1, 2020 at 8:11 AM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
>
> From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> > Recovery performance measurement results below.
> > But it seems there are overhead even with large shared buffers.
> >
> > | s_b   | master | patched | %reg  |
> > |-------|--------|---------|-------|
> > | 128MB | 36.052 | 39.451  | 8.62% |
> > | 1GB   | 21.731 | 21.73   | 0.00% |
> > | 20GB  | 24.534 | 25.137  | 2.40% |
> > | 100GB | 30.54  | 31.541  | 3.17% |
>
> Did you really check that the optimization path is entered and the traditional path is never entered?
>

I have one idea for performance testing. We can even test this for
non-recovery paths by removing the recovery-related check like only
use it when there are cached blocks. You can do this if testing via
recovery path is difficult because at the end performance should be
same for recovery and non-recovery paths.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Disable WAL logging to speed up data loading