Re: Read-ahead and parallelism in redo recovery

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