Re: Bug: Buffer cache is not scan resistant

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Bug: Buffer cache is not scan resistant
Дата
Msg-id 45EDB747.90003@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Bug: Buffer cache is not scan resistant  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug: Buffer cache is not scan resistant  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> If I were to implement this idea, I think Heikki's bitmap of pages
>> already read is the way to go.
> 
> I think that's a good way to guarantee that you'll not finish in time
> for 8.3.  Heikki's idea is just at the handwaving stage at this point,
> and I'm not even convinced that it will offer any win.  (Pages in
> cache will be picked up by a seqscan already.)

The scenario that I'm worried about is that you have a table that's 
slightly larger than RAM. If you issue many seqscans on that table, one 
at a time, every seqscan will have to read the whole table from disk, 
even though say 90% of it is in cache when the scan starts.

This can be alleviated by using a large enough sync_scan_offset, but a 
single setting like that is tricky to tune, especially if your workload 
is not completely constant. Tune it too low, and you don't get much 
benefit, tune it too high and your scans diverge and you lose all benefit.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: GIST and TOAST
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Auto creation of Partitions