Re: Performance TODO items

> 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