Re: Read-ahead and parallelism in redo recovery

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Read-ahead and parallelism in redo recovery
Дата
Msg-id 87bq5zz98b.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Read-ahead and parallelism in redo recovery  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список pgsql-hackers
Florian G. Pflug wrote:
> The same holds true for index scans, though. Maybe we can find a
> solution that benefits both cases - something along the line of a
> bgreader process

I posted a patch to do readahead for bitmap index scans using posix_fadvise.
Experiments showed it works great on raid arrays on Linux. Solaris will need
to use libaio though which I haven't tried yet.

Incidentally, I'm off on a ski vacation this week so I won't be around much on
email for the first half of the commit-fest. If anyone's putting together a
list of patches queued up for review I would like this patch considered. 

The main feedback I'm blocking on is whether others are interested in
restructuring the buffer manager to allow buffers to be allocated and pinned
with only the posix_fadvise i/o initiated. That would avoid the redundant trip
into the buffer manager for the usual case at the expense of a few buffers
being taken out of the cache. The patch I posted is the minimally invasive
approach of not altering the buffer management at all and just passing through
a readahead request.

I looked at doing it for normal index scans and couldn't think of any
convenient way. I can see getting a single buffer of read-ahead from the index
block's next pointer but that's about it. Luckily it seems to me that bitmap
index scans are much more likely to be chosen in the cases where there's a big
gain anyways.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



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

Предыдущее
От: Decibel!
Дата:
Сообщение: Re: pg_dump additional options for performance
Следующее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: Read-ahead and parallelism in redo recovery