Re: [Patch] Optimize dropping of relation buffers using dlist
От | Amit Kapila |
---|---|
Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | CAA4eK1JAAfthUBGodnphucehZU3PonoWhOenhytFXA_=trWVAA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>) |
Список | pgsql-hackers |
On Mon, Oct 12, 2020 at 3:08 PM k.jamison@fujitsu.com <k.jamison@fujitsu.com> wrote: > > Hmm. When I repeated the performance measurement for non-recovery, > I got almost similar execution results for both master and patched. > > Execution Time (in seconds) > | s_b | master | patched | %reg | > |-------|--------|---------|--------| > | 128MB | 15.265 | 14.769 | -3.36% | > | 1GB | 14.808 | 14.618 | -1.30% | > | 20GB | 24.673 | 24.425 | -1.02% | > | 100GB | 74.298 | 74.813 | 0.69% | > > That is considering that I removed the recovery-related checks in the patch and just > executed the commands on a standalone server. > - if (InRecovery && reln->smgr_cached_nblocks[forknum] != InvalidBlockNumber) > + if (reln->smgr_cached_nblocks[forknum] != InvalidBlockNumber) > Why so? Have you tried to investigate? Check if it takes an optimized path for the non-recovery case? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: