From a0185461dd94c8d31d8d55a7f2839b0d2f172ab9 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 11 Oct 2011 14:20:06 -0400 Subject: Rearrange the implementation of index-only scans. This commit changes index-only scans so that data is read directly from the index tuple without first generating a faux heap tuple. The only immediate benefit is that indexes on system columns (such as OID) can be used in index-only scans, but this is necessary infrastructure if we are ever to support index-only scans on expression indexes. The executor is now ready for that, though the planner still needs substantial work to recognize the possibility. To do this, Vars in index-only plan nodes have to refer to index columns not heap columns. I introduced a new special varno, INDEX_VAR, to mark such Vars to avoid confusion. (In passing, this commit renames the two existing special varnos to OUTER_VAR and INNER_VAR.) This allows ruleutils.c to handle them with logic similar to what we use for subplan reference Vars. Since index-only scans are now fundamentally different from regular indexscans so far as their expression subtrees are concerned, I also chose to change them to have their own plan node type (and hence, their own executor source file). --- src/backend/executor/nodeHash.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/backend/executor/nodeHash.c') diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c index e72a71bf51b..091aef90e0a 100644 --- a/src/backend/executor/nodeHash.c +++ b/src/backend/executor/nodeHash.c @@ -755,8 +755,8 @@ ExecHashTableInsert(HashJoinTable hashtable, * Compute the hash value for a tuple * * The tuple to be tested must be in either econtext->ecxt_outertuple or - * econtext->ecxt_innertuple. Vars in the hashkeys expressions reference - * either OUTER or INNER. + * econtext->ecxt_innertuple. Vars in the hashkeys expressions should have + * varno either OUTER_VAR or INNER_VAR. * * A TRUE result means the tuple's hash value has been successfully computed * and stored at *hashvalue. A FALSE result means the tuple cannot match -- cgit v1.2.3