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

relnode.c

Blame
    • Tom Lane's avatar
      a9db37a1
      Generate EquivalenceClass members for partitionwise child join rels. · a9db37a1
      Tom Lane authored
      Commit d25ea012 got rid of what I thought were entirely unnecessary
      derived child expressions in EquivalenceClasses for EC members that
      mention multiple baserels.  But it turns out that some of the child
      expressions that code created are necessary for partitionwise joins,
      else we fail to find matching pathkeys for Sort nodes.  (This happens
      only for certain shapes of the resulting plan; it may be that
      partitionwise aggregation is also necessary to show the failure,
      though I'm not sure of that.)
      
      Reverting that commit entirely would be quite painful performance-wise
      for large partition sets.  So instead, add code that explicitly
      generates child expressions that match only partitionwise child join
      rels we have actually generated.
      
      Per report from Justin Pryzby.  (Amit Langote noticed the problem
      earlier, though it's not clear if he recognized then that it could
      result in a planner error, not merely failure to exploit partitionwise
      join, in the code as-committed.)  Back-patch to v12 where commit
      d25ea012 came in.
      
      Amit Langote, with lots of kibitzing from me
      
      Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com
      Discussion: https://postgr.es/m/20191011143703.GN10470@telsasoft.com
      a9db37a1
      History
      Generate EquivalenceClass members for partitionwise child join rels.
      Tom Lane authored
      Commit d25ea012 got rid of what I thought were entirely unnecessary
      derived child expressions in EquivalenceClasses for EC members that
      mention multiple baserels.  But it turns out that some of the child
      expressions that code created are necessary for partitionwise joins,
      else we fail to find matching pathkeys for Sort nodes.  (This happens
      only for certain shapes of the resulting plan; it may be that
      partitionwise aggregation is also necessary to show the failure,
      though I'm not sure of that.)
      
      Reverting that commit entirely would be quite painful performance-wise
      for large partition sets.  So instead, add code that explicitly
      generates child expressions that match only partitionwise child join
      rels we have actually generated.
      
      Per report from Justin Pryzby.  (Amit Langote noticed the problem
      earlier, though it's not clear if he recognized then that it could
      result in a planner error, not merely failure to exploit partitionwise
      join, in the code as-committed.)  Back-patch to v12 where commit
      d25ea012 came in.
      
      Amit Langote, with lots of kibitzing from me
      
      Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com
      Discussion: https://postgr.es/m/20191011143703.GN10470@telsasoft.com