Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
52799: colexec: implement resizing in the hash table r=yuzefovich a=yuzefovich **colexec: improve benchmarks of hash aggregation and some cleanup** Previously, we would populate groups in ordered fashion for both ordered and hash aggregators, but this is not very realistic in case of the hash aggregation. This commit makes the groups distribution random (but still adhering to the target group sizes). It also adds variation of number of input batches to the benchmark of the aggregators. This commit also removes an unused parameter from the tuple distributor. Release note: None **colexec: clean up mixed-type equality checks in the joins** We currently only support the cases of same-type as well as integers of mixed widths in the equality conditions (all other allowed mixed-type comparisons are pushed into the ON condition, see 43060), so we will now generate the code only for same-type comparisons and for integer ones in the hash table. This limitation became apparent when the resizing of the hash table was put in place, and TestHashJoinerAgainstProcessor became flaky. Note that the test could flake before, but it was impossibly unlikely - we had a fixed large number of hash buckets, so the chance of a hash collision was a lot lower. This commit updates the test to deflake it (to generate comparable types only of the cases that could occur in non-test environment) as well as updates the hash table template to not generate some dead code. Release note: None **colexec: implement resizing in the hash table** This commit implements the resizing logic in the vectorized hash table. Previously, the number of hash buckets has been fixed at 2^16 and now it'll start out at coldata.BatchSize() and will grow exponentitally while maintaining the target load factor (the average number of tuples per bucket). Note that we don't have a maximum number of buckets because this commit also adds memory accounting for the internal auxiliary slices of the hash table. Not having a maximum is acceptable because every bucket takes up 16 bytes, and if we are going to hit the memory limit, mostly likely it'll be because of the tuples stored in `ht.vals` and `buildScratch.next` slice (which is of the same length as `ht.vals`). All users of the hash table (hash joiner, hash aggregator, and unordered distinct) have been benchmarked using microbenchmarks and TPCH queries and the load factor has been chosen separately. I also tried out different initial numbers of buckets, but using coldata.BatchSize() showed the most stable performance. The reasoning for such choice: - on one hand, we make several other allocations that have to be at least coldata.BatchSize() in size, so we don't win much in the case of the input with small number of tuples; - on the other hand, if we start out with a larger number, we won't be using vast of majority of the buckets on the input with small number of tuples (a downside) while not gaining much in the case of the input with large number of tuples. #Fixes: #52257. Release note: None 52817: kvcoord: key range cache entries by regular keys, not meta keys r=andreimatei a=andreimatei Before this patch, entries in the range cache were keyed by RangeMetaKey(desc.EndKey). There were no good reasons why either the RangeMetaKey() transformation was used, or why the EndKey was used instead of the StartKey. Presumably this has all been done in order to match how descriptors are stored in the meta ranges, but this was misguided since it's confusing. This patch makes cache entries simply be keyed on desc.Start. This fixes a problem with querying the cache with RKeyMin.Next(). Before this patch, this query was broken since it was failing to find the cached Meta1 range: the range was [RKeyMin, Meta2Start), and so it was keyed at RangeMetaKey(Meta2Start) = Meta1/Meta2Start. The cache lookup was using RangeMetaKey(RKeyMin.Next), which results in /Meta2/<something> (which is too high) because of arguably a bug in the implementation of RangeMetaKey. Fixing that bug proves to not be quite straigh-forward (#52786). This patch fixes the problem by not needing to apply neither .Next() nor RangeMetaKey() when performing cache lookups. This patch fixes the issues referenced below; what the restores in those issues were experiencing was a spectacular consequence of the failure to lookup the cache described above: evicting the Meta1 descriptor from the cache was always failing (because the lookup was failing) which, in turn, was causing the DistSender to believe that it was perpetually receiving old lease information and so it would loop around contacting the same replica over and over. There's something to improve in the DistSender, coming separately. While the underlying RangeMetaKey() bug is old, I believe this bug was exposed more by the recent range cache changes. It used to be that we would generally evict the Meta1 descriptor from the cache based on the key that caused that descriptor to be inserted in the cache. Now we generally evict the descriptor based on the range's start key (which is RKeyMin, and suffers from the RKeyMin.Next() issue). Fixes #52468 Fixes #52391 Fixes #50987 Release note: None 53105: intentresolver: misc cleanups r=andreimatei a=andreimatei See individual commits. 53134: tree: remove pointer definition for DBox2D r=sumeerbhola a=otan Box2D should never actually be nil inside, so remove that requirement. Resolves #53013. Release note: None Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: Andrei Matei <[email protected]> Co-authored-by: Oliver Tan <[email protected]>
- Loading branch information