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
      8693ebe3
      Avoid some zero-divide hazards in the planner. · 8693ebe3
      Tom Lane authored
      Although I think on all modern machines floating division by zero
      results in Infinity not SIGFPE, we still don't want infinities
      running around in the planner's costing estimates; too much risk
      of that leading to insane behavior.
      
      grouping_planner() failed to consider the possibility that final_rel
      might be known dummy and hence have zero rowcount.  (I wonder if it
      would be better to set a rows estimate of 1 for dummy relations?
      But at least in the back branches, changing this convention seems
      like a bad idea, so I'll leave that for another day.)
      
      Make certain that get_variable_numdistinct() produces a nonzero result.
      The case that can be shown to be broken is with stadistinct < 0.0 and
      small ntuples; we did not prevent the result from rounding to zero.
      For good luck I applied clamp_row_est() to all the nonconstant return
      values.
      
      In ExecChooseHashTableSize(), Assert that we compute positive nbuckets
      and nbatch.  I know of no reason to think this isn't the case, but it
      seems like a good safety check.
      
      Per reports from Piotr Stefaniak.  Back-patch to all active branches.
      8693ebe3
      History
      Avoid some zero-divide hazards in the planner.
      Tom Lane authored
      Although I think on all modern machines floating division by zero
      results in Infinity not SIGFPE, we still don't want infinities
      running around in the planner's costing estimates; too much risk
      of that leading to insane behavior.
      
      grouping_planner() failed to consider the possibility that final_rel
      might be known dummy and hence have zero rowcount.  (I wonder if it
      would be better to set a rows estimate of 1 for dummy relations?
      But at least in the back branches, changing this convention seems
      like a bad idea, so I'll leave that for another day.)
      
      Make certain that get_variable_numdistinct() produces a nonzero result.
      The case that can be shown to be broken is with stadistinct < 0.0 and
      small ntuples; we did not prevent the result from rounding to zero.
      For good luck I applied clamp_row_est() to all the nonconstant return
      values.
      
      In ExecChooseHashTableSize(), Assert that we compute positive nbuckets
      and nbatch.  I know of no reason to think this isn't the case, but it
      seems like a good safety check.
      
      Per reports from Piotr Stefaniak.  Back-patch to all active branches.