From cbfa92c23c3924d53889320cdbe26f23ee23e40c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 9 Oct 2011 00:21:08 -0400 Subject: Improve index-only scans to avoid repeated access to the index page. We copy all the matched tuples off the page during _bt_readpage, instead of expensively re-locking the page during each subsequent tuple fetch. This costs a bit more local storage, but not more than 2*BLCKSZ worth, and the reduction in LWLock traffic is certainly worth that. What's more, this lets us get rid of the API wart in the original patch that said an index AM could randomly decline to supply an index tuple despite having asserted pg_am.amcanreturn. That will be important for future improvements in the index-only-scan feature, since the executor will now be able to rely on having the index data available. --- doc/src/sgml/indexam.sgml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index 724b413755d..80f55da87b3 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -394,12 +394,13 @@ amgettuple (IndexScanDesc scan, If the access method supports index-only scans (i.e., amcanreturn is TRUE in its pg_am row), then on success it must also check - scan->xs_want_itup, and if that is true it should return + scan->xs_want_itup, and if that is true it must return the original indexed data for the index entry, in the form of an - IndexTuple stored at scan->xs_itup. However, - it is permissible for the access method to sometimes fail to provide this - data, in which case it must set scan->xs_itup to NULL. That - will result in a regular heap fetch occurring. + IndexTuple pointer stored at scan->xs_itup. + (Management of the data referenced by the pointer is the access method's + responsibility. The data must remain good at least until the next + amgettuple, amrescan, or amendscan + call for the scan.) -- cgit v1.2.3