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  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: [Patch] Optimize dropping of relation buffers using dlist
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Disable WAL logging to speed up data loading