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

nodeHash.c

Blame
    • Tom Lane's avatar
      f4e4b327
      Support RIGHT and FULL OUTER JOIN in hash joins. · f4e4b327
      Tom Lane authored
      This is advantageous first because it allows us to hash the smaller table
      regardless of the outer-join type, and second because hash join can be more
      flexible than merge join in dealing with arbitrary join quals in a FULL
      join.  For merge join all the join quals have to be mergejoinable, but hash
      join will work so long as there's at least one hashjoinable qual --- the
      others can be any condition.  (This is true essentially because we don't
      keep per-inner-tuple match flags in merge join, while hash join can do so.)
      
      To do this, we need a has-it-been-matched flag for each tuple in the
      hashtable, not just one for the current outer tuple.  The key idea that
      makes this practical is that we can store the match flag in the tuple's
      infomask, since there are lots of bits there that are of no interest for a
      MinimalTuple.  So we aren't increasing the size of the hashtable at all for
      the feature.
      
      To write this without turning the hash code into even more of a pile of
      spaghetti than it already was, I rewrote ExecHashJoin in a state-machine
      style, similar to ExecMergeJoin.  Other than that decision, it was pretty
      straightforward.
      f4e4b327
      History
      Support RIGHT and FULL OUTER JOIN in hash joins.
      Tom Lane authored
      This is advantageous first because it allows us to hash the smaller table
      regardless of the outer-join type, and second because hash join can be more
      flexible than merge join in dealing with arbitrary join quals in a FULL
      join.  For merge join all the join quals have to be mergejoinable, but hash
      join will work so long as there's at least one hashjoinable qual --- the
      others can be any condition.  (This is true essentially because we don't
      keep per-inner-tuple match flags in merge join, while hash join can do so.)
      
      To do this, we need a has-it-been-matched flag for each tuple in the
      hashtable, not just one for the current outer tuple.  The key idea that
      makes this practical is that we can store the match flag in the tuple's
      infomask, since there are lots of bits there that are of no interest for a
      MinimalTuple.  So we aren't increasing the size of the hashtable at all for
      the feature.
      
      To write this without turning the hash code into even more of a pile of
      spaghetti than it already was, I rewrote ExecHashJoin in a state-machine
      style, similar to ExecMergeJoin.  Other than that decision, it was pretty
      straightforward.