Re: Bug: Buffer cache is not scan resistant

Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>
>> Shared Buffers Elapsed IO rate (from vmstat)
>> -------------- ------- ---------------------
>> 400MB 101 s 122 MB/s
>> 2MB 100 s
>> 1MB 97 s
>> 768KB 93 s
>> 512KB 86 s
>> 256KB 77 s
>> 128KB 74 s 166 MB/s
>>
>
> So I'm back to asking what we're really measuring here. Buffer manager
> inefficiency of some sort, but what? Have you tried oprofile?
>
Isn't the size of the shared buffer pool itself acting as a performance
penalty in this case ? May be StrategyGetBuffer() needs to make multiple
passes over the buffers before the usage_count of any buffer is reduced
to zero and the buffer is chosen as replacement victim.

There is no real advantage of having larger shared buffer pool in this
particular test. A heap buffer is hardly accessed again once the seqscan
passes over it. Can we try with a smaller value for
BM_MAX_USAGE_COUNT and see if that has any positive impact
for large shared pool in this case ?

Thanks,
Pavan