Re: Bug: Buffer cache is not scan resistant

Поиск
Список
Период
Сортировка
От Gavin Sherry
Тема Re: Bug: Buffer cache is not scan resistant
Дата
Msg-id Pine.LNX.4.58.0703051614070.19071@linuxworld.com.au
обсуждение исходный текст
Ответ на Re: Bug: Buffer cache is not scan resistant  (Mark Kirkwood <markir@paradise.net.nz>)
Ответы Re: Bug: Buffer cache is not scan resistant  ("Luke Lonergan" <LLonergan@greenplum.com>)
Re: Bug: Buffer cache is not scan resistant  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bug: Buffer cache is not scan resistant  (Mark Kirkwood <markir@paradise.net.nz>)
Список pgsql-hackers
On Mon, 5 Mar 2007, Mark Kirkwood wrote:

> To add a little to this - forgetting the scan resistant point for the
> moment... cranking down shared_buffers to be smaller than the L2 cache
> seems to help *any* sequential scan immensely, even on quite modest HW:
>
> e.g: PIII 1.26Ghz 512Kb L2 cache, 2G ram,
>
> SELECT count(*) FROM lineitem (which is about 11GB) performance:
>
> Shared_buffers  Elapsed
> --------------  -------
> 400MB           101 s
> 128KB            74 s
>
> When I've profiled this activity, I've seen a lot of time spent
> searching for/allocating a new buffer for each page being fetched.
> Obviously having less of them to search through will help, but having
> less than the L2 cache-size worth of 'em seems to help a whole lot!

Could you demonstrate that point by showing us timings for shared_buffers
sizes from 512K up to, say, 2 MB? The two numbers you give there might
just have to do with managing a large buffer.

Thanks,

Gavin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Bug: Buffer cache is not scan resistant
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Bug: Buffer cache is not scan resistant