On Thursday, October 1, 2020 11:49 AM, Amit Kapila wrote: > On Thu, Oct 1, 2020 at 8:11 AM tsunakawa.ta...@fujitsu.com > <tsunakawa.ta...@fujitsu.com> wrote: > > > > From: Jamison, Kirk/ジャミソン カーク <k.jami...@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? > >
Oops. Thanks Tsunakawa-san for catching that. Will fix in the next patch, replacing break with continue. > 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. For non-recovery path, did you mean by any chance measuring the cache hit rate for varying shared_buffers? SELECT sum(heap_blks_read) as heap_read, sum(heap_blks_hit) as heap_hit, sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio FROM pg_statio_user_tables; Regards, Kirk Jamison
