Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1+9sn7Qx4ne+GJUQZSJK56JKjVBSKx-nNS+H2GnS0XZ2g@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Ответы |
RE: [Patch] Optimize dropping of relation buffers using dlist
RE: [Patch] Optimize dropping of relation buffers using dlist |
Список | 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 по дате отправления: