Re: Bug: Buffer cache is not scan resistant
| От | Tom Lane |
|---|---|
| Тема | Re: Bug: Buffer cache is not scan resistant |
| Дата | |
| Msg-id | 19602.1173113616@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Bug: Buffer cache is not scan resistant (Mark Kirkwood <markir@paradise.net.nz>) |
| Ответы |
Re: Bug: Buffer cache is not scan resistant
Re: Bug: Buffer cache is not scan resistant Re: Bug: Buffer cache is not scan resistant |
| Список | 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 по дате отправления: