mirror of
https://github.com/postgres/postgres.git
synced 2025-07-15 19:21:59 +03:00
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).
This commit is contained in:
@ -199,14 +199,15 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel)
|
||||
true, NULL, SAOP_FORBID, ST_ANYSCAN);
|
||||
|
||||
/*
|
||||
* Submit all the ones that can form plain IndexScan plans to add_path. (A
|
||||
* plain IndexPath always represents a plain IndexScan plan; however some
|
||||
* of the indexes might support only bitmap scans, and those we mustn't
|
||||
* submit to add_path here.) Also, pick out the ones that might be useful
|
||||
* as bitmap scans. For that, we must discard indexes that don't support
|
||||
* bitmap scans, and we also are only interested in paths that have some
|
||||
* selectivity; we should discard anything that was generated solely for
|
||||
* ordering purposes.
|
||||
* Submit all the ones that can form plain IndexScan plans to add_path.
|
||||
* (A plain IndexPath might represent either a plain IndexScan or an
|
||||
* IndexOnlyScan, but for our purposes here the distinction does not
|
||||
* matter. However, some of the indexes might support only bitmap scans,
|
||||
* and those we mustn't submit to add_path here.) Also, pick out the ones
|
||||
* that might be useful as bitmap scans. For that, we must discard
|
||||
* indexes that don't support bitmap scans, and we also are only
|
||||
* interested in paths that have some selectivity; we should discard
|
||||
* anything that was generated solely for ordering purposes.
|
||||
*/
|
||||
bitindexpaths = NIL;
|
||||
foreach(l, indexpaths)
|
||||
@ -1107,11 +1108,9 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
|
||||
|
||||
/*
|
||||
* For the moment, we just ignore index expressions. It might be nice
|
||||
* to do something with them, later. We also ignore index columns
|
||||
* that are system columns (such as OID), because the virtual-tuple
|
||||
* coding used by IndexStoreHeapTuple() can't deal with them.
|
||||
* to do something with them, later.
|
||||
*/
|
||||
if (attno <= 0)
|
||||
if (attno == 0)
|
||||
continue;
|
||||
|
||||
index_attrs =
|
||||
|
Reference in New Issue
Block a user