| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
| Cc: | Gavin Sherry <swm(at)alcove(dot)com(dot)au>, Luke Lonergan <llonergan(at)greenplum(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Doug Rady <drady(at)greenplum(dot)com>, Sherry Moore <sherry(dot)moore(at)sun(dot)com> |
| Subject: | Re: Bug: Buffer cache is not scan resistant |
| Date: | 2007-03-05 16:53:36 |
| Message-ID: | 19602.1173113616@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-03-05 16:54:17 | Re: HOT - whats next ? |
| Previous Message | Tom Lane | 2007-03-05 16:39:57 | Re: HOT - whats next ? |