On Thursday, October 1, 2020 11:49 AM, Amit Kapila wrote:
> 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?
> >
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