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 по дате отправления: