Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

trigger.c

Blame
    • Tom Lane's avatar
      a0185461
      Rearrange the implementation of index-only scans. · a0185461
      Tom Lane authored
      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).
      a0185461
      History
      Rearrange the implementation of index-only scans.
      Tom Lane authored
      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).