Re: Bug: Buffer cache is not scan resistant

Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.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