Re: proposal: be smarter about i/o patterns in index scan

"Jeffrey W. Baker" <jwbaker(at)acm(dot)org> writes:
> No doubt, you can't just naively create giant vectors of TIDs and expect
> to sort them. Is there any concept in Pg of an unrealized result?

Only for the case of a partially-read plan result. That is, we do this
for rowsets, but not for scalars or arrays. A lot of the point of the
LIMIT 1 example is that it is exploiting the fact that we won't ever
materialize the full output of the indexscan.

> If you scanned an index building up a result set that was totally
> unrealized, except for the TID and the index columns, you could
> cheaply join two such results without ever touching the heap. You
> could also use the existing Sort execution step to sort such a result.
> Then don't touch the heap something accesses a non-index column, or
> because you are returning the result somewhere and need to satisfy
> MVCC visibility limits.

This is basically what I was talking about with IndexOnlyScan/TidExpand.

regards, tom lane