You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Change "long" numGroups fields to be Cardinality (i.e., double).
We've been nibbling away at removing uses of "long" for a long time,since its width is platform-dependent. Here's one more: change theremaining "long" fields in Plan nodes to Cardinality, since the threesurviving examples all represent group-count estimates. The upstreamplanner code was converted to Cardinality some time ago; for examplethe corresponding fields in Path nodes are type Cardinality, as arethe arguments of the make_foo_path functions. Downstream in theexecutor, it turns out that these all feed to the table-size argumentof BuildTupleHashTable. Change that to "double" as well, and fix itso that it safely clamps out-of-range values to the uint32 limit ofsimplehash.h, as was not being done before.Essentially, this is removing all the artificial datatype-dependentlimitations on these values from upstream processing, and applyingjust one clamp at the moment where we're forced to do so by thedatatype choices of simplehash.h.Also, remove BuildTupleHashTable's misguided attempt to enforcework_mem/hash_mem_limit. It doesn't have enough information(particularly not the expected tuple width) to do that accurately,and it has no real business second-guessing the caller's choice.For all these plan types, it's really the planner's responsibilityto not choose a hashed implementation if the hashtable is expectedto exceed hash_mem_limit. The previous patch improved theaccuracy of those estimates, and even if BuildTupleHashTable hadmore information it should arrive at the same conclusions.Reported-by: Jeff Janes <jeff.janes@gmail.com>Author: Tom Lane <tgl@sss.pgh.pa.us>Reviewed-by: David Rowley <dgrowleyml@gmail.com>Discussion:https://postgr.es/m/CAMkU=1zia0JfW_QR8L5xA2vpa0oqVuiapm78h=WpNsHH13_9uw@mail.gmail.com