"Decibel!" <decibel@decibel.org> writes:
> On Dec 4, 2007, at 1:42 PM, Gregory Stark wrote:
>> I'm debating between two ways to structure the code right now. Do I put the
>> logic to peek ahead in nodeBitmapHeapScan to read ahead and remember the
>> info
>> seen or in tidbitmap with an new api function which is only really useful
>> for
>> this one use case.
>
>
> There has been discussion of having a bg_reader, similar to the bg_writer.
> Perhaps that would be better than creating something that's specific to bitmap
> scans?
Has there? AFAICT a bg_reader only makes sense if we move to a direct-i/o
situation where we're responsible for read-ahead and have to read into shared
buffers any blocks we decide are interesting to readahead.
Regardless of what mechanism is used and who is responsible for doing it
someone is going to have to figure out which blocks are specifically
interesting to prefetch. Bitmap index scans happen to be the easiest since
we've already built up a list of blocks we plan to read. Somehow that
information has to be pushed to the storage manager to be acted upon.
Normal index scans are an even more interesting case but I'm not sure how hard
it would be to get that information. It may only be convenient to get the
blocks from the last leaf page we looked at, for example.
> Also, I would expect to see a speed improvement even on single drives if the
> OS is actually issuing multiple requests to the drive. Doing so allows the
> drive to optimally order all of the reads.
Sure, but a 2x speed improvement? That's way more than I was expecting
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
