> A more general solution is for indexscan to collect up a bunch of TIDs
> from the index, sort them in-memory by TID order, and then probe into
> the heap with those TIDs. This is better than the above because you get
> nice ordering of the heap accesses across multiple key values, not just
> among the tuples with the same key. (In a unique or near-unique index,
> the above idea is nearly worthless.)
>
> In the best case there are few enough TIDs retrieved from the index that
> you can just do this once, but even if there are lots of TIDs, it should
> be a win to do this in batches of a few thousand TIDs. Essentially we
> decouple indexscans into separate index-access and heap-access phases.
>
> One big problem is that this doesn't interact well with concurrent VACUUM:
> our present solution for concurrent VACUUM assumes that indexscans hold
> a pin on an index page until they've finished fetching the pointed-to
> heap tuples. Another objection is that we'd have a harder time
> implementing the TODO item of marking an indextuple dead when its
> associated heaptuple is dead. Anyone see a way around these problems?
Interesting. I figured the cache could keep most pages in such a case.
I was thinking more of helping file system readahead by requesting the
earlier block first in a mult-block request. Not sure how valuable that
would be.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
