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  ("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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: HOT - whats next ?
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Latest plans for Utilities with HOT