Hi
This idea is due to Robert Haas, who complained that he feared that
the streaming I/O API already worked like this. It doesn't, but it
could! Here is a concept patch to try it out.
Normally, read_stream_next_buffer() spits out buffers in the order
that the user's callback generated block numbers. This option says
that any order would be OK.
I had been assuming that this sort of thing would come with real
asynchronous I/O: if I/Os complete out of order and the caller
explicitly said she doesn't care about block order, we can stream them
as the completion events arrive. But even with synchronous I/O, we
could stream already-in-cache blocks before ones that require I/O.
Letting the caller chew on blocks that are already available maximises
the time between fadvise() and preadv() for misses, which minimises
the likelihood that the process will have to go to "D" sleep.
The patch is pretty trivial: if started with the
READ_STREAM_OUT_OF_ORDER flag, "hit" buffers are allowed to jump in
front of "miss" buffers in the queue. The attached coding may not be
optimal, it's just a proof of concept.
ANALYZE benefits from this, for example, with certain kinds of
partially cached initial states and fast disks (?). I'm not sure how
generally useful it is though. I'm posting it because I wonder if it
could be interesting for the streaming bitmap heapscan project, and I
wonder how many other things don't care about the order.
