Re: Bug: Buffer cache is not scan resistant - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug: Buffer cache is not scan resistant
Date
Msg-id 19602.1173113616@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug: Buffer cache is not scan resistant  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: Bug: Buffer cache is not scan resistant  ("Pavan Deolasee" <pavan@enterprisedb.com>)
Re: Bug: Buffer cache is not scan resistant  ("Luke Lonergan" <llonergan@greenplum.com>)
Re: Bug: Buffer cache is not scan resistant  ("Luke Lonergan" <llonergan@greenplum.com>)
List pgsql-hackers
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

Hm, that seems to blow the "it's an L2 cache effect" theory out of the
water.  If it were a cache effect then there should be a performance
cliff at the point where the cache size is exceeded.  I see no such
cliff, in fact the middle part of the curve is darn near a straight
line on a log scale ...

So I'm back to asking what we're really measuring here.  Buffer manager
inefficiency of some sort, but what?  Have you tried oprofile?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HOT - whats next ?
Next
From: "Pavan Deolasee"
Date:
Subject: Re: Latest plans for Utilities with HOT