Partitioned Vectorized Hash Join for Cache Containment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Hash join operations in database systems face inefficiencies due to high latency caused by cache misses and branch mispredictions, especially when dealing with large hash tables that exceed the CPU cache, leading to suboptimal performance on modern hardware architectures.
Innovation Solution
The technique involves partitioning large tables into smaller, cache-contained subsets, allowing each partition to be fully loaded into a node's cache, using a hash bucket array and link array to efficiently generate and probe the hash table, thereby minimizing cache misses and branch mispredictions through a partition-based vectorized hash join approach.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If large hash tables are generated to handle large datasets, then the join operation can process more data, but cache misses increase leading to high latency
Solution Approach 1:
The patent divides the large hash table into multiple smaller hash tables, each stored in different CPU caches. This segmentation allows each cache to remain small and fast, while collectively handling large datasets. The hash table is partitioned based on hash bucket ranges, with each partition fitting within a single cache memory structure.
Solution Approach 2:
The patent introduces a partition dimension to the traditional hash table structure. Instead of a single large hash table, multiple hash tables are organized across different cache levels and CPU cores, adding a spatial distribution dimension that reduces cache miss latency while maintaining large data processing capacity.
2Device complexity
If a single large hash table is used, then the structure is simple, but branch mispredictions increase due to complex probing patterns
Solution Approach 1:
The patent segments the hash table into multiple smaller tables, each with more predictable probing patterns. This reduces the complexity of branch prediction within each individual hash table, as each handles a subset of data with more uniform access patterns, thereby reducing branch mispredictions.
3Quantity of substance
If the hash table is stored in DRAM main-memory, then large datasets can be accommodated, but access latency increases significantly
Solution Approach 1:
The patent segments the large hash table into multiple smaller hash tables that fit within CPU caches (L1/L2 cache). This allows the hash tables to be stored in fast cache memory rather than slow DRAM, significantly improving lookup speed while collectively accommodating large datasets through distribution across multiple caches and CPU cores.
Solution Approach 2:
The patent moves the storage dimension from a single large DRAM structure to multiple distributed cache structures across different CPU cores. This dimensional change enables fast cache-based access for each partition while maintaining the ability to handle large overall dataset sizes.
4Loss of time
If partitioning is applied to enable cache containment, then cache misses are reduced, but the system complexity increases
Solution Approach 1:
The patent implements partitioning by dividing the hash table into segments based on hash bucket ranges. Each partition is independently managed and fits within a single CPU cache, eliminating cache misses for data within each partition. The segmentation is performed automatically based on hash values, reducing manual partition management complexity.
Data Source
AI summary
Techniques are described for generation of an efficient hash table for probing during join operations. A node stores a partition and generates a hash table that includes a hash bucket array and a link array, where the link array is index aligned to the partition. Each hash bucket element contains an offset that defines a location of a build key array element in the partition and a link array element in the link array. For a particular build key array element, the node determines a hash bucket element that corresponds to the build key array. If the hash bucket element contains an existing offset, the existing offset is copied to the link array element that corresponds to the offset of the particular build key array element and the offset for the particular build key array element is copied into the hash bucket element. When probing, the offset in a hash bucket element is used to locate a build key array element and other offsets stored in the link array for additional build key array elements.