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

nodeMergejoin.c

Blame
    • Tom Lane's avatar
      f39d57b8
      Rejigger mergejoin logic so that a tuple with a null in the first merge column · f39d57b8
      Tom Lane authored
      is treated like end-of-input, if nulls sort last in that column and we are not
      doing outer-join filling for that input.  In such a case, the tuple cannot
      join to anything from the other input (because we assume mergejoinable
      operators are strict), and neither can any tuple following it in the sort
      order.  If we're not interested in doing outer-join filling we can just
      pretend the tuple and its successors aren't there at all.  This can save a
      great deal of time in situations where there are many nulls in the join
      column, as in a recent example from Scott Marlowe.  Also, since the planner
      tends to not count nulls in its mergejoin scan selectivity estimates, this
      is an important fix to make the runtime behavior more like the estimate.
      
      I regard this as an omission in the patch I wrote years ago to teach mergejoin
      that tuples containing nulls aren't joinable, so I'm back-patching it.  But
      only to 8.3 --- in older versions, we didn't have a solid notion of whether
      nulls sort high or low, so attempting to apply this optimization could break
      things.
      f39d57b8
      History
      Rejigger mergejoin logic so that a tuple with a null in the first merge column
      Tom Lane authored
      is treated like end-of-input, if nulls sort last in that column and we are not
      doing outer-join filling for that input.  In such a case, the tuple cannot
      join to anything from the other input (because we assume mergejoinable
      operators are strict), and neither can any tuple following it in the sort
      order.  If we're not interested in doing outer-join filling we can just
      pretend the tuple and its successors aren't there at all.  This can save a
      great deal of time in situations where there are many nulls in the join
      column, as in a recent example from Scott Marlowe.  Also, since the planner
      tends to not count nulls in its mergejoin scan selectivity estimates, this
      is an important fix to make the runtime behavior more like the estimate.
      
      I regard this as an omission in the patch I wrote years ago to teach mergejoin
      that tuples containing nulls aren't joinable, so I'm back-patching it.  But
      only to 8.3 --- in older versions, we didn't have a solid notion of whether
      nulls sort high or low, so attempting to apply this optimization could break
      things.