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

nodeSubqueryscan.c

Blame
    • Tom Lane's avatar
      b3aaf908
      Rearrange planner to save the whole PlannerInfo (subroot) for a subquery. · b3aaf908
      Tom Lane authored
      Formerly, set_subquery_pathlist and other creators of plans for subqueries
      saved only the rangetable and rowMarks lists from the lower-level
      PlannerInfo.  But there's no reason not to remember the whole PlannerInfo,
      and indeed this turns out to simplify matters in a number of places.
      
      The immediate reason for doing this was so that the subroot will still be
      accessible when we're trying to extract column statistics out of an
      already-planned subquery.  But now that I've done it, it seems like a good
      code-beautification effort in its own right.
      
      I also chose to get rid of the transient subrtable and subrowmark fields in
      SubqueryScan nodes, in favor of having setrefs.c look up the subquery's
      RelOptInfo.  That required changing all the APIs in setrefs.c to pass
      PlannerInfo not PlannerGlobal, which was a large but quite mechanical
      transformation.
      
      One side-effect not foreseen at the beginning is that this finally broke
      inheritance_planner's assumption that replanning the same subquery RTE N
      times would necessarily give interchangeable results each time.  That
      assumption was always pretty risky, but now we really have to make a
      separate RTE for each instance so that there's a place to carry the
      separate subroots.
      b3aaf908
      History
      Rearrange planner to save the whole PlannerInfo (subroot) for a subquery.
      Tom Lane authored
      Formerly, set_subquery_pathlist and other creators of plans for subqueries
      saved only the rangetable and rowMarks lists from the lower-level
      PlannerInfo.  But there's no reason not to remember the whole PlannerInfo,
      and indeed this turns out to simplify matters in a number of places.
      
      The immediate reason for doing this was so that the subroot will still be
      accessible when we're trying to extract column statistics out of an
      already-planned subquery.  But now that I've done it, it seems like a good
      code-beautification effort in its own right.
      
      I also chose to get rid of the transient subrtable and subrowmark fields in
      SubqueryScan nodes, in favor of having setrefs.c look up the subquery's
      RelOptInfo.  That required changing all the APIs in setrefs.c to pass
      PlannerInfo not PlannerGlobal, which was a large but quite mechanical
      transformation.
      
      One side-effect not foreseen at the beginning is that this finally broke
      inheritance_planner's assumption that replanning the same subquery RTE N
      times would necessarily give interchangeable results each time.  That
      assumption was always pretty risky, but now we really have to make a
      separate RTE for each instance so that there's a place to carry the
      separate subroots.