> 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
