Pith. sign in

REVIEW 2 major objections 6 minor 64 references

Eiger speeds up single-GPU analytics by choosing operator variants at runtime from cheap data statistics, beating a fixed library by up to 1.8× overall and 6.1× on individual TPC-H queries.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-11 18:42 UTC pith:DUPDPROP

load-bearing objection Solid systems paper: multi-variant GPU operators plus cheap runtime stats deliver measured 1.8× TPC-H gains over cuDF; heuristics are a real but non-load-bearing limit. the 2 major comments →

arxiv 2607.04489 v1 pith:DUPDPROP submitted 2026-07-05 cs.DB

Eiger: An Efficient Library for GPU-based Data Analytics

Bowen Wu , Marko Kabi\'c , Sven Hepkema , Vasilis Mageirakos , Christos Kozyrakis , Gustavo Alonso This is my paper
classification cs.DB
keywords GPU databasesruntime adaptivityrelational operatorsTPC-HHyperLogLog++smart key fusionexpression evaluationstring matching
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Once data already sits in GPU memory and the interconnect is fast, the time spent inside relational operators dominates. Existing GPU libraries lock most operators to one fixed algorithm and ignore intermediate data properties, so they leave large performance on the table across different cardinalities, string lengths, key distributions, and GPU generations. Eiger supplies several implementations and knobs for joins, group-bys, expression evaluation, string matching, and multi-key sorting, then measures lightweight statistics (value ranges, means, HyperLogLog++ sketches) on intermediate columns during execution. Those statistics pick the algorithm, set the knobs, and even compress keys on the fly so that a cheaper radix sort can replace merge sort. The resulting adaptive library cuts total TPC-H runtime by as much as 1.8 imes and individual queries by as much as 6.1 imes while also mapping when each variant wins. A reader who builds or tunes GPU analytics engines cares because the same two-part recipe—rich operator catalog plus cheap runtime profiling—turns static one-size-fits-all code into a system that stays near the best choice for each workload and hardware.

Core claim

Runtime workload adaptivity—pairing multiple implementation variants and tunable knobs per operator with lightweight GPU-side statistics collected on intermediate data—is sufficient to push single-GPU relational query performance well beyond a state-of-the-art fixed library such as cuDF, delivering up to 1.8 imes lower total TPC-H time and up to 6.1 imes on individual queries.

What carries the argument

Runtime adaptive execution: min/max/mean values and HyperLogLog++ sketches computed at near-memory-bandwidth cost, used to select among operator variants, tune configuration knobs, and drive on-the-fly key compression (smart key fusion with order-preserving dictionary encoding).

Load-bearing premise

The hand-chosen lightweight statistics and simple selection heuristics always pick a near-best operator variant with negligible overhead for the data shapes and GPU architectures that matter.

What would settle it

Run the same TPC-H and micro-benchmark suite on a third GPU architecture or on intermediate distributions deliberately outside the current heuristics; if the adaptive choice systematically selects a slower variant or the statistics overhead exceeds the gain, the claimed end-to-end speedups disappear.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 6 minor

Summary. Eiger is a single-GPU analytics library that argues runtime workload adaptivity—multiple operator variants plus cheap intermediate-data statistics—is the missing ingredient relative to cuDF’s one-size-fits-all design. It supplies hash/partitioned-hash/sort-merge joins with GFUR/GFTR materialization; hash/sort/partition group-bys; PTI and batch expression backends with Sethi–Ullman linearization; packed multi-byte string matching with cooperative-group parallelism and optional KMP; and multi-key sorting via smart key fusion (frame-of-reference/bitpacking or order-preserving dictionary encoding) into radix-sortable keys. At runtime it profiles min/max/mean and HyperLogLog++ sketches to choose algorithms, tune knobs, and compress keys. Microbenchmarks on A100 and GH200 systematically vary cardinality, match ratio, string length/alignment, and group cardinality; end-to-end TPC-H (SF 10/30/100) reports up to 1.8× total and 6.1× per-query speedups versus a cuDF-backed engine (Maximus).

Significance. If the measured results hold, the paper is a substantial systems contribution for GPU analytics. It treats expression evaluation, string processing, and multi-key sorting with the same seriousness as joins and group-bys, contributes concrete techniques (alignment-safe packed string access, order-preserving GPU dictionary encoding, SKF), and provides a broader operator-level characterization across two GPU generations than prior work. The empirical case that GPU-side statistics are cheap enough to pay for themselves (e.g., HLL++ ~1 ms vs. large sort/group-by mispredictions) is well supported and useful for future cost models. Strengths include systematic microbenchmarks, full TPC-H, and an explicit baseline-vs-best breakdown that separates better implementations of the same algorithms from variant selection.

major comments (2)
  1. §5.7 and Table 5: Eiger (best) is described as combining “the best-performing implementation of each operator,” while Eiger (baseline) mirrors cuDF’s algorithm choices. It is not fully clear whether TPC-H “best” configurations are chosen by the paper’s runtime heuristics (HLL++, string-length rules, SKF compressibility tests, PTI/BB thresholds) or by offline oracle selection informed by the microbenchmarks. Because the abstract and introduction frame the end-to-end gains as evidence for runtime workload adaptivity, the manuscript should state explicitly, per operator class, which decisions were automatic at query time versus hand-selected. Without that, readers cannot tell how much of the 1.8× total / 6.1× per-query numbers support automatic selection versus the richer variant catalog alone.
  2. §4 and Table 1: The free parameters that drive selection—NDV/group-cardinality cutoffs for hash vs. sort vs. partition group-by, string-length/pattern heuristics for CG size and packed width, range/NDV thresholds for FoR+bitpacking vs. dictionary encoding in SKF, and the intermediate-result size threshold for register-resident PTI vs. shared-memory PTI vs. batch backend—are described qualitatively but not reported as concrete values (or as a small decision table) used in the experiments. These thresholds are load-bearing for the adaptivity claim and for reproducibility of the “Auto” series (§5.3.2) and SKF results (§5.6). Please list the thresholds used on GH200/A100 and note whether they were held fixed across TPC-H scale factors.
minor comments (6)
  1. §3.1: The 64-bit size_type choice is well motivated, but several join/group-by comparisons note that HJ inserts 8-byte TIDs while PHJ/SMJ can operate on 4-byte keys. A short note on whether a 32-bit TID mode was measured (or why not) would help readers separate size_type cost from algorithm cost.
  2. §5.4 / Figure 7: Relative PTI vs. BB preference flips between A100 and GH200; the text explains this via memory bandwidth, but a one-line rule of thumb (or the register-threshold used) would make the takeaway easier to apply.
  3. §5.5: KMP is included but rarely wins; a brief statement of when the authors would still recommend it (or that it is mainly for completeness) would avoid over-interpreting its presence in Table 1.
  4. Figure 14: Operator-time breakdowns are informative; adding a small legend note that “baseline” disables SKF and uses PTI/hash defaults (as in §5.7) would make the figure self-contained.
  5. Related work (§6): The distinction from Themis (intra-operator load imbalance vs. inter-variant selection) is clear; a sentence on how Eiger’s library API is intended to plug into engines such as Maximus/GQE would strengthen the composability claim in the conclusion.
  6. Typos/consistency: “EV ALUATION” spacing in the §5 heading; “the the partition hash join” in §5.7; arXiv IDs in the reference list appear to use future-dated numbers—verify against the camera-ready bibliography.

Circularity Check

0 steps flagged

No significant circularity: empirical systems paper whose speedups are measured against an external baseline, not derived by construction from fitted inputs or self-citation.

full rationale

Eiger is an engineering and evaluation paper. Its central claims (up to 1.8× total and 6.1× per-query TPC-H speedups vs cuDF/Maximus on SF 10/30/100, plus operator microbenchmarks on A100 and GH200) are obtained by executing the library and reporting wall-clock times; they do not rest on a mathematical derivation that reduces to its own inputs. Runtime statistics (min/max/mean, HLL++) and hand-written selection heuristics are used to choose among independently implemented variants; the paper reports the cost of those statistics and shows they are small relative to the gains of the chosen algorithm (e.g., §5.3.2 Auto series, §5.6/Table 4 SKF). Self-citations to Wu et al. [55] supply concrete join/group-by building blocks that Eiger extends; they are not invoked as uniqueness theorems or as the sole evidence that the new adaptive results hold. There is no fitted parameter renamed as a prediction, no self-definitional identity, and no ansatz smuggled in via citation that forces the reported speedups. The work is therefore self-contained against external benchmarks and exhibits no circularity of the kinds enumerated.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 2 invented entities

Systems paper whose claims rest on standard GPU programming model assumptions, the full-materialization columnar execution model common to cuDF-class libraries, and a handful of hand-chosen selection thresholds/heuristics. No physical constants or deep mathematical axioms; free parameters are the practical cut-offs used by the adaptive logic.

free parameters (4)
  • NDV / group-cardinality thresholds for hash vs. sort vs. partition group-by
    Used by the Auto selector (Fig. 6); exact numeric cut-offs are platform- and type-dependent and chosen empirically rather than derived.
  • String-length and pattern-length heuristics for packed-access width and cooperative-group size
    Section 4.2 heuristic; values that decide [parallelism, access-width] pairs are hand-tuned from microbenchmarks.
  • Range and NDV thresholds that trigger frame-of-reference/bitpacking or dictionary encoding in smart key fusion
    Section 4.3; compressibility cut-offs determine whether radix sort becomes applicable.
  • Register-resident intermediate-result size threshold for PTI vs. shared-memory PTI vs. batch backend
    Section 3.5; decides when expression intermediates stay in registers.
axioms (4)
  • domain assumption Full materialization of intermediate columns between operators is the execution model (no pipelined volcano/vector model).
    Stated in §2.2; matches cuDF and underpins all operator interfaces and late-materialization TID strategies.
  • domain assumption GPU statistics (min/max/mean, HLL++) can be computed at near-memory-bandwidth cost and therefore amortize easily.
    Core premise of §4; supported by microbenchmarks but treated as generally true for current HBM GPUs.
  • domain assumption Arrow-style offset+data string layout is preferable to German strings for the targeted workloads.
    §3.4.1; justified by preliminary study but fixed for all subsequent string results.
  • ad hoc to paper 64-bit size_type / TIDs are required for future-proofing despite higher bandwidth cost.
    §3.1 design choice that affects join and sort costs relative to 32-bit cuDF.
invented entities (2)
  • Smart key fusion (SKF) with order-preserving dictionary encoding independent evidence
    purpose: Compress and fuse multiple sort/group keys into a single 4- or 8-byte key so radix sort can replace merge sort.
    New algorithm (Alg. 1) introduced in §4.3; independent evidence is the measured 12–13× sort speedups, but the entity itself is a software technique rather than a physical postulate.
  • Packed multi-byte string access with on-the-fly pattern duplication for alignment independent evidence
    purpose: Enable wide loads on arbitrarily aligned concatenated strings.
    §3.4.2 technique; validated by prefix/exact-match microbenchmarks.

pith-pipeline@v1.1.0-grok45 · 32925 in / 3146 out tokens · 31859 ms · 2026-07-11T18:42:44.858380+00:00 · methodology

0 comments
read the original abstract

GPUs have become an increasingly attractive platform for accelerating analytical workloads due to their massive parallelism and high memory bandwidth. Recent studies show that in systems with fast CPU-GPU interconnects and networks, query processing within the GPU, rather than data movement, is the dominant bottleneck. This highlights the need for more efficient relational operators on GPUs than the widely used library, cuDF. While offering rich functionality, cuDF commits to a single, statically chosen implementation for most operators and barely uses runtime information about the data, limiting performance across diverse workloads and GPUs. We present Eiger, a high-performance library for GPU-based data analytics that improves single-GPU query processing through runtime workload adaptivity. Adaptivity in Eiger rests on two principles. First, Eiger provides multiple implementation variants and tunable knobs for most operators, covering not only joins and group-bys but also expensive yet often overlooked operations, such as expression evaluation, string processing, and multi-key sorting, for which it contributes new optimization techniques. Second, Eiger profiles intermediate data during query execution using lightweight statistics, such as value ranges and HyperLogLog++ sketches, and uses them to select implementations, tune knobs, and compress data on the fly, overcoming the limitations of traditional static query optimization. The breadth of operators and variants also enables a more comprehensive performance analysis, covering more operations and workloads than previous work. We evaluate Eiger with operator microbenchmarks on two GPU architectures and the complete TPC-H benchmark (up to scale factor 100). Across the 22 queries, Eiger reduces total runtime by up to 1.8x compared to the state-of-the-art cuDF library; for individual queries, Eiger achieves up to 6.1x better performance.

Figures

Figures reproduced from arXiv: 2607.04489 by Bowen Wu, Christos Kozyrakis, Gustavo Alonso, Marko Kabi\'c, Sven Hepkema, Vasilis Mageirakos.

Figure 1
Figure 1. Figure 1: String matching with packed accesses. 3.4.1 Layout. In-memory string columns typically adopt one of two layouts, the old Arrow format [53] and the German string format [32]. Like cuDF, Eiger chooses the Arrow format mainly for two reasons. First, the German string format needs more space to store the string column due to the explicit length field if the majority of strings cannot be inlined into the header… view at source ↗
Figure 2
Figure 2. Figure 2: Narrow join with fixed |𝑆 | = 2 28 (GH200). 2 12 2 16 2 20 2 24 2 28 |R| 3 4 5 6 7 8 9 10 11 Thpt (Billion Tuples/s) SMJ/UR PHJ/UR HJ SMJ/TR PHJ/TR (a) 4-byte join key (GH200). 2 12 2 16 2 20 2 24 2 28 |R| 3 4 5 6 7 8 Thpt (Billion Tuples/s) SMJ/UR PHJ/UR HJ SMJ/TR PHJ/TR (b) 8-byte join key (GH200). 2 12 2 16 2 20 2 24 2 28 |R| 2 3 4 5 6 Thpt (Billion Tuples/s) SMJ/UR PHJ/UR HJ SMJ/TR PHJ/TR (c) 4-byte jo… view at source ↗
Figure 3
Figure 3. Figure 3: Wide join with fixed |𝑆 | = 2 28 (3a-3c) or |𝑆 | = 2 27 (3d). 5.2 Joins We evaluate the hash join (HJ), partitioned hash join (PHJ), and sort￾merge join (SMJ). Our hash join uses the same static_multiset implementation from cuCollection with cuDF; therefore, we skip comparing to cuDF in this experiment. For PHJ and SMJ, we con￾sider two materialization strategies: GFUR (gather-from-untransformed￾relations)… view at source ↗
Figure 4
Figure 4. Figure 4: shows the results for GH200. A100 has similar results. In the narrow join scenario, for both 4-byte and 8-byte join keys, HJ performs the best for small |𝑆 | (up to 2 19 for 4-byte keys, and up to 2 22 for 8-byte keys). This agrees with the results of the previous experiment that HJ has a greater advantage for I64 keys. Interest￾ingly, the results show that SMJ outperforms PHJ for medium 𝑆 2 18 2 22 2 26 |… view at source ↗
Figure 5
Figure 5. Figure 5: Effect of match ratio on join performance. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 8
Figure 8. Figure 8: String prefix matching microbenchmarks (GH200). [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: String exact matching microbenchmark (GH200). [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Substring matching microbenchmarks. help when the string length increases. For shorter patterns (e.g., pattern length=30), additional threads provide little benefit, while 2-byte access can help. At pattern length 45, one thread and 1-byte access is most efficient, possibly because string lengths are odd. For larger patterns, the optimal parallelism differs by GPUs: at pattern length 90, GH200 prefers 2 t… view at source ↗
Figure 12
Figure 12. Figure 12: String sorting microbenchmarks [PITH_FULL_IMAGE:figures/full_fig_p012_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Sort microbenchmark. SKF = smart key fusion. [PITH_FULL_IMAGE:figures/full_fig_p012_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: TPC-H SF=100 breakdown (GH200). provides multiple implementation variants and tunable knobs for each operator, including expensive but often overlooked operations such as expression evaluation, string processing, and multi-key sorting, and it profiles intermediate data during query execution with lightweight statistics to select implementations, tune knobs, and compress data on the fly. Our evaluation sho… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

64 extracted references · 8 canonical work pages

  1. [1]

    Hellerstein

    Ron Avnur and Joseph M. Hellerstein. 2000. Eddies: continuously adaptive query processing.SIGMOD Rec.29, 2 (May 2000), 261–272. https://doi.org/10.1145/ 335191.335420

    arXiv 2000

  2. [2]

    Daniel Bauer, Luis Garces-Erice, Deepak Majeti, Zoltan Arnold Nagy, Sean Rooney, Greg Kimball, Devavret Makkar, Todd Mostak, and Karthikeyan Natara- jan. 2026. Accelerating Presto with GPUs. arXiv:2606.24647 [cs.DB] https: //arxiv.org/abs/2606.24647

    Pith/arXiv arXiv 2026

  3. [3]

    Nils Boeschen, Tobias Ziegler, and Carsten Binnig. 2024. GOLAP: A GPU-in- Data-Path Architecture for High-Speed OLAP.Proc. ACM Manag. Data2, 6, Article 237 (Dec. 2024), 26 pages. https://doi.org/10.1145/3698812

    doi:10.1145/3698812 2024

  4. [4]

    (last accessed) 2026

    Rani Borkar and Nidhi Chappell. (last accessed) 2026. Microsoft Azure delivers the first large scale cluster with NVIDIA GB300 NVL72 for OpenAI workloads. [Online] Available from: https://azure.microsoft.com/en-us/blog/microsoft- azure-delivers-the-first-large-scale-cluster-with-nvidia-gb300-nvl72-for- openai-workloads/

    2026

  5. [5]

    Santam- brogio

    Beatrice Branchini, Pierluigi Negro, Ian Di Dio Lavore, and Marco D. Santam- brogio. 2025. Harnessing GPU Acceleration for Exact DNA Sequence Matching via the KMP Algorithm. In2025 IEEE International Symposium on Circuits and Systems (ISCAS). 1–5. https://doi.org/10.1109/ISCAS56072.2025.11043676

    doi:10.1109/iscas56072.2025.11043676 2025

  6. [6]

    Jiashen Cao, Rathijit Sen, Matteo Interlandi, Joy Arulraj, and Hyesoon Kim. 2023. GPU Database Systems Characterization and Optimization.Proc. VLDB Endow. 17, 3 (nov 2023), 441–454. https://doi.org/10.14778/3632093.3632107

    doi:10.14778/3632093.3632107 2023

  7. [7]

    Periklis Chrysogelos, Manos Karpathiotakis, Raja Appuswamy, and Anastasia Ailamaki. 2019. HetExchange: encapsulating heterogeneous CPU-GPU paral- lelism in JIT compiled engines.Proc. VLDB Endow.12, 5 (Jan. 2019), 544–556. https://doi.org/10.14778/3303753.3303760

    doi:10.14778/3303753.3303760 2019

  8. [8]

    (last accessed) 2026

    NVIDIA Corporation. (last accessed) 2026. NVIDIA Kicks Off the Next Gener- ation of AI With Rubin — Six New Chips, One Incredible AI Supercomputer. [Online] Available from: https://nvidianews.nvidia.com/news/rubin-platform- ai-supercomputer

    2026

  9. [9]

    Amol Deshpande, Zachary Ives, and Vijayshankar Raman. 2007. Adaptive query processing.Found. Trends Databases1, 1 (Jan. 2007), 1–140

    2007

  10. [10]

    Harish Doraiswamy, Vikas Kalagi, Karthik Ramachandra, and Jayant R. Haritsa

  11. [11]

    VLDB Endow.16, 10 (jun 2023), 2499–2511

    A Case for Graphics-Driven Query Processing.Proc. VLDB Endow.16, 10 (jun 2023), 2499–2511. https://doi.org/10.14778/3603581.3603590

    work page doi:10.14778/3603581.3603590 2023

  12. [12]

    Mark Harris and RAPIDS Development Team. 2020. [FEA] Make cudf::size_type 64-bit. GitHub Issue #3958, https://github.com/rapidsai/cudf/ issues/3958. RAPIDS cuDF repository. Accessed: 2026-05-19

    2020

  13. [13]

    Dong He, Supun C Nakandala, Dalitso Banda, Rathijit Sen, Karla Saur, Kwanghyun Park, Carlo Curino, Jesús Camacho-Rodríguez, Konstantinos Karana- sos, and Matteo Interlandi. 2022. Query processing on tensor computation run- times.Proc. VLDB Endow.15, 11 (July 2022), 2811–2825. https://doi.org/10.14778/ 3551793.3551833

    arXiv 2022

  14. [14]

    Sven Hepkema, Azim Afroozeh, Charlotte Felius, Peter Boncz, and Stefan Mane- gold. 2025. G-ALP: Rethinking Light-weight Encodings for GPUs. InProceedings of the 21st International Workshop on Data Management on New Hardware (Da- MoN ’25). Association for Computing Machinery, New York, NY, USA, Article 11, 10 pages. https://doi.org/10.1145/3736227.3736242

    doi:10.1145/3736227.3736242 2025

  15. [15]

    Stefan Heule, Marc Nunkesser, and Alexander Hall. 2013. HyperLogLog in prac- tice: algorithmic engineering of a state of the art cardinality estimation algorithm. InProceedings of the 16th International Conference on Extending Database Tech- nology(Genoa, Italy)(EDBT ’13). Association for Computing Machinery, New York, NY, USA, 683–692. https://doi.org/10...

    doi:10.1145/2452376.2452456 2013

  16. [16]

    Kijae Hong, Kyoungmin Kim, Young-Koo Lee, Yang-Sae Moon, Sourav S Bhowmick, and Wook-Shin Han. 2024. Themis: A GPU-Accelerated Rela- tional Query Execution Engine.Proc. VLDB Endow.18, 2 (Oct. 2024), 426–438. https://doi.org/10.14778/3705829.3705856

    doi:10.14778/3705829.3705856 2024

  17. [17]

    Yu-Ching Hu, Yuliang Li, and Hung-Wei Tseng. 2022. TCUDB: Accelerating Database with Tensor Processors. InProceedings of the 2022 International Con- ference on Management of Data(Philadelphia, PA, USA)(SIGMOD ’22). Asso- ciation for Computing Machinery, New York, NY, USA, 1360–1374. https: //doi.org/10.1145/3514221.3517869

    doi:10.1145/3514221.3517869 2022

  18. [18]

    Zezhou Huang, Krystian Sakowski, Hans Lehnert, Wei Cui, Carlo Curino, Matteo Interlandi, Marius Dumitru, and Rathijit Sen. 2025. GPU Acceleration of SQL Analytics on Compressed Data. arXiv:2506.10092 [cs.DB] https://arxiv.org/abs/ 2506.10092

    Pith/arXiv arXiv 2025

  19. [19]

    Marko Kabić, Shriram Chandran, and Gustavo Alonso. 2025. Maximus: A Modular Accelerated Query Engine for Data Analytics on Heterogeneous Systems.Proc. ACM Manag. Data3, 3, Article 187 (June 2025), 25 pages. https://doi.org/10.1145/ 3725324

    2025

  20. [20]

    Marko Kabić, Bowen Wu, Jonas Dann, and Gustavo Alonso. 2025. Powerful GPUs or Fast Interconnects: Analyzing Relational Workloads on Modern GPUs.Proc. VLDB Endow.18, 11 (Sept. 2025), 4350–4363. https://doi.org/10.14778/3749646. 3749698 Eiger: An Efficient Library for GPU-based Data Analytics

    doi:10.14778/3749646 2025

  21. [21]

    Tim Kaldewey, Guy Lohman, Rene Mueller, and Peter Volk. 2012. GPU join processing revisited. InProceedings of the Eighth International Workshop on Data Management on New Hardware(Scottsdale, Arizona)(DaMoN ’12). Association for Computing Machinery, New York, NY, USA, 55–62. https://doi.org/10.1145/ 2236584.2236592

    arXiv 2012

  22. [22]

    Tomas Karnagel, René Müller, and Guy M. Lohman. 2015. Optimizing GPU-accelerated Group-By and Aggregation. InADMS@VLDB. https://api. semanticscholar.org/CorpusID:5017248

    2015

  23. [23]

    (last accessed) 2026

    Gregory Kimball, Zoltán Arnold Nagy, Devavret Makkar, Daniel Bauer, and Chengcheng Jin. (last accessed) 2026. Accelerating Large-Scale Data An- alytics with GPU-Native Velox and NVIDIA cuDF. [Online] Available from: https://developer.nvidia.com/blog/accelerating-large-scale-data-analytics- with-gpu-native-velox-and-nvidia-cudf/

    2026

  24. [24]

    Donald E Knuth, James H Morris, Jr, and Vaughan R Pratt. 1977. Fast pattern matching in strings.SIAM journal on computing6, 2 (1977), 323–350

    1977

  25. [25]

    Artem Kroviakov, Petr Kurapov, Christoph Anneser, and Jana Giceva. 2024. Heterogeneous Intra-Pipeline Device-Parallel Aggregations. InProceedings of the 20th International Workshop on Data Management on New Hardware(Santiago, AA, Chile)(DaMoN ’24). Association for Computing Machinery, New York, NY, USA, Article 3, 10 pages. https://doi.org/10.1145/3662010.3663441

    doi:10.1145/3662010.3663441 2024

  26. [26]

    Maas, Momin Al-Ghosien, Spyros Blanas, Nicolas Bruno, Carlo Curino, Matteo Interlandi, Craig Peeper, Kaushik Rajan, Surajit Chaudhuri, and Johannes Gehrke

    Yinan Li, Bailu Ding, Ziyun Wei, Lukas M. Maas, Momin Al-Ghosien, Spyros Blanas, Nicolas Bruno, Carlo Curino, Matteo Interlandi, Craig Peeper, Kaushik Rajan, Surajit Chaudhuri, and Johannes Gehrke. 2025. Scaling GPU-Accelerated Databases Beyond GPU Memory Size.Proc. VLDB Endow.18, 11 (Sept. 2025), 4518–4531. https://doi.org/10.14778/3749646.3749710

    doi:10.14778/3749646.3749710 2025

  27. [27]

    Haotian Liu, Bo Tang, Jiashu Zhang, Yangshen Deng, Xinying Zheng, Qiaomu Shen, Xiao Yan, Dan Zeng, Zunyao Mao, Chaozu Zhang, Zhengxin You, Zhihao Wang, Runzhe Jiang, Fang Wang, Man Lung Yiu, Huan Li, Mingji Han, Qian Li, and Zhenghai Luo. 2022. GHive: A Demonstration of GPU-Accelerated Query Processing in Apache Hive. InProceedings of the 2022 Internation...

    arXiv 2022

  28. [28]

    Jigao Luo, Nils Boeschen, Muhammad El-Hindi, and Carsten Binnig. 2026. Pysta- chIO: Efficient Distributed GPU Query Processing with PyTorch over Fast Net- works & Fast Storage. arXiv:2512.02862 [cs.DB] https://arxiv.org/abs/2512.02862

    Pith/arXiv arXiv 2026

  29. [30]

    InProceedings of the 2020 ACM SIGMOD International Conference on Management of Data(Portland, OR, USA)(SIGMOD ’20)

    Pump Up the Volume: Processing Large Data on GPUs with Fast Inter- connects. InProceedings of the 2020 ACM SIGMOD International Conference on Management of Data(Portland, OR, USA)(SIGMOD ’20). Association for Comput- ing Machinery, New York, NY, USA, 1633–1649. https://doi.org/10.1145/3318464. 3389705

    doi:10.1145/3318464 2020

  30. [31]

    Clemens Lutz, Sebastian Breß, Steffen Zeuch, Tilmann Rabl, and Volker Markl

  31. [32]

    InProceedings of the 2022 International Conference on Management of Data(Philadelphia, PA, USA)(SIGMOD ’22)

    Triton Join: Efficiently Scaling to a Large Join State on GPUs with Fast In- terconnects. InProceedings of the 2022 International Conference on Management of Data(Philadelphia, PA, USA)(SIGMOD ’22). Association for Computing Machin- ery, New York, NY, USA, 1017–1032. https://doi.org/10.1145/3514221.3517911

    doi:10.1145/3514221.3517911 2022

  32. [33]

    Vasilis Mageirakos, Joel André, Marko Kabić, Bowen Wu, Yannis Chronis, and Gustavo Alonso. 2026. To GPU or Not to GPU: Vector Search in Relational Engines. arXiv:2605.15957 [cs.DB] https://arxiv.org/abs/2605.15957

    Pith/arXiv arXiv 2026

  33. [34]

    Hubert Mohr-Daurat, Xuan Sun, and Holger Pirk. 2023. BOSS - An Architecture for Database Kernel Composition.Proc. VLDB Endow.17, 4 (Dec. 2023), 877–890. https://doi.org/10.14778/3636218.3636239

    doi:10.14778/3636218.3636239 2023

  34. [35]

    Thomas Neumann and Michael J. Freitag. 2020. Umbra: A Disk-Based System with In-Memory Performance. InConference on Innovative Data Systems Research. https://www.cidrdb.org/cidr2020/papers/p29-neumann-cidr20.pdf

    2020

  35. [36]

    (last accessed) 2026

    NVIDIA. (last accessed) 2026. cuCollections. [Online] Available from: https: //github.com/NVIDIA/cuCollections/tree/dev

    2026

  36. [37]

    (last accessed) 2026

    Oracle. (last accessed) 2026. SQL Tuning Guide (Chapter 10: Optimizer Statistics Concepts). [Online] Available from: https://docs.oracle.com/en/database/oracle/ oracle-database/26/tgsql/optimizer-statistics-concepts.html

    2026

  37. [38]

    Tsuyoshi Ozawa and Kazuo Goda. 2026. Data Path Fusion in GPU for Analytical Query Processing. arXiv:2605.10511 [cs.DB] https://arxiv.org/abs/2605.10511

    Pith/arXiv arXiv 2026

  38. [39]

    Johns Paul, Bingsheng He, Shengliang Lu, and Chiew Tong Lau. 2019. Revisiting Hash Join on Graphics Processors: A Decade Later. In2019 IEEE 35th International Conference on Data Engineering Workshops (ICDEW). 294–299. https://doi.org/ 10.1109/ICDEW.2019.00008

    doi:10.1109/icdew.2019.00008 2019

  39. [40]

    Pedro Pedreira, Orri Erling, Konstantinos Karanasos, Scott Schneider, Wes McKin- ney, Satya R Valluri, Mohamed Zait, and Jacques Nadeau. 2023. The Composable Data Management System Manifesto.Proc. VLDB Endow.16, 10 (June 2023), 2679–2685. https://doi.org/10.14778/3603581.3603604

    doi:10.14778/3603581.3603604 2023

  40. [41]

    (last accessed) 2026

    PostgreSQL. (last accessed) 2026. PostgreSQL 18 Documentation (Chapter 14.2: Statistics Used by the Planner). [Online] Available from: https://www.postgresql. org/docs/current/planner-stats.html

    2026

  41. [42]

    2003.Database management systems (3 ed.)

    Raghu Ramakrishnan and Johannes Gehrke. 2003.Database management systems (3 ed.). McGraw-Hill New York

    2003

  42. [43]

    (last accessed) 2026

    RAPIDS. (last accessed) 2026. cuDF: A GPU DataFrame Library. [Online] Available from: https://github.com/rapidsai/cudf

    2026

  43. [44]

    (last accessed) 2026

    RAPIDS. (last accessed) 2026. GQE: GPU Query Engine. https://github.com/ rapidsai/gqe

    2026

  44. [45]

    Viktor Rosenfeld, Sebastian Breß, Steffen Zeuch, Tilmann Rabl, and Volker Markl

  45. [46]

    InProceedings of the 15th International Workshop on Data Management on New Hardware(Amsterdam, Netherlands)(DaMoN’19)

    Performance Analysis and Automatic Tuning of Hash Aggregation on GPUs. InProceedings of the 15th International Workshop on Data Management on New Hardware(Amsterdam, Netherlands)(DaMoN’19). Association for Computing Machinery, New York, NY, USA, Article 8, 11 pages. https://doi.org/10.1145/ 3329785.3329922

    arXiv

  46. [47]

    Ran Rui and Yi-Cheng Tu. 2017. Fast Equi-Join Algorithms on GPUs: Design and Implementation. InProceedings of the 29th International Conference on Scientific and Statistical Database Management(Chicago, IL, USA)(SSDBM ’17). Association for Computing Machinery, New York, NY, USA, Article 17, 12 pages. https: //doi.org/10.1145/3085504.3085521

    doi:10.1145/3085504.3085521 2017

  47. [48]

    Ravi Sethi and J. D. Ullman. 1970. The Generation of Optimal Code for Arithmetic Expressions.J. ACM17, 4 (Oct. 1970), 715–728. https://doi.org/10.1145/321607. 321620

    work page doi:10.1145/321607 1970

  48. [49]

    Anil Shanbhag, Samuel Madden, and Xiangyao Yu. 2020. A Study of the Funda- mental Performance Characteristics of GPUs and CPUs for Database Analytics. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data(Portland, OR, USA)(SIGMOD ’20). Association for Computing Machinery, New York, NY, USA, 1617–1632. https://doi.org/10.114...

    doi:10.1145/3318464.3380595 2020

  49. [50]

    Yogatama, Xiangyao Yu, and Samuel Madden

    Anil Shanbhag, Bobbi W. Yogatama, Xiangyao Yu, and Samuel Madden. 2022. Tile-based Lightweight Integer Compression in GPU. InProceedings of the 2022 International Conference on Management of Data(Philadelphia, PA, USA)(SIG- MOD ’22). Association for Computing Machinery, New York, NY, USA, 1390–1403. https://doi.org/10.1145/3514221.3526132

    work page doi:10.1145/3514221.3526132 2022

  50. [51]

    Sean Wang, Xiaodong Zhang, and Rubao Lee

    Xuri Shi, Kai Zhang, X. Sean Wang, Xiaodong Zhang, and Rubao Lee. 2026. RayDB: Building Databases with Ray Tracing Cores.Proc. VLDB Endow.19, 1 (Jan. 2026), 43–55. https://doi.org/10.14778/3772181.3772185

    work page doi:10.14778/3772181.3772185 2026

  51. [52]

    Panagiotis Sioulas, Periklis Chrysogelos, Manos Karpathiotakis, Raja Ap- puswamy, and Anastasia Ailamaki. 2019. Hardware-Conscious Hash-Joins on GPUs. In2019 IEEE 35th International Conference on Data Engineering (ICDE). 698–709. https://doi.org/10.1109/ICDE.2019.00068

    work page doi:10.1109/icde.2019.00068 2019

  52. [53]

    Sitaridi and Kenneth A

    Evangelia A. Sitaridi and Kenneth A. Ross. 2016. GPU-accelerated string matching for database applications.The VLDB Journal25, 5 (Oct. 2016), 719–740. https: //doi.org/10.1007/s00778-015-0409-y

    work page doi:10.1007/s00778-015-0409-y 2016

  53. [54]

    Wenbo Sun, Asterios Katsifodimos, and Rihan Hai. 2023. An Empirical Per- formance Comparison between Matrix Multiplication Join and Hash Join on GPUs. In2023 IEEE 39th International Conference on Data Engineering Workshops (ICDEW). 184–190. https://doi.org/10.1109/ICDEW58674.2023.00034

    work page doi:10.1109/icdew58674.2023.00034 2023

  54. [55]

    Tomé, Tim Gubner, Mark Raasveldt, Eyal Rozenberg, and Peter A

    Diego G. Tomé, Tim Gubner, Mark Raasveldt, Eyal Rozenberg, and Peter A. Boncz

  55. [56]

    In ADMS@VLDB

    Optimizing Group-By and Aggregation using GPU-CPU Co-Processing. In ADMS@VLDB. https://api.semanticscholar.org/CorpusID:52895287

  56. [57]

    2022.TPC Benchmark H (Deci- sion Support) Standard Specification

    Transaction Processing Performance Council. 2022.TPC Benchmark H (Deci- sion Support) Standard Specification. Technical Report. Transaction Processing Performance Council (TPC). https://www.tpc.org/TPC_Documents_Current_ Versions/pdf/TPC-H_v3.0.1.pdf Version 3.0.1

    2022

  57. [58]

    (last accessed) 2026

    David Wendt and Gregory Kimball. (last accessed) 2026. Mastering String Trans- formations in RAPIDS libcudf. [Online] Available from: https://developer.nvidia. com/blog/mastering-string-transformations-in-rapids-libcudf/

    2026

  58. [59]

    Bowen Wu, Wei Cui, Carlo Curino, Matteo Interlandi, and Rathijit Sen. 2025. Terabyte-Scale Analytics in the Blink of an Eye.Proc. VLDB Endow.19, 2 (Oct. 2025), 141–155. https://doi.org/10.14778/3773749.3773754

    doi:10.14778/3773749.3773754 2025

  59. [60]

    Bowen Wu, Dimitrios Koutsoukos, and Gustavo Alonso. 2025. Efficiently Pro- cessing Joins and Grouped Aggregations on GPUs.Proc. ACM Manag. Data3, 1, Article 39 (Feb. 2025), 27 pages. https://doi.org/10.1145/3709689

    doi:10.1145/3709689 2025

  60. [61]

    Bobbi Yogatama, Weiwei Gong, and Xiangyao Yu. 2025. Scaling your Hybrid CPU- GPU DBMS to Multiple GPUs.Proc. VLDB Endow.17, 13 (Feb. 2025), 4709–4722. https://doi.org/10.14778/3704965.3704977

    doi:10.14778/3704965.3704977 2025

  61. [62]

    Bobbi Yogatama, Yifei Yang, Kevin Kristensen, Devesh Sarda, Abigale Kim, Adrian Cockcroft, Yu Teng, Joshua Patterson, Gregory Kimball, Wes McKinney, Weiwei Gong, and Xiangyao Yu. 2025. Rethinking Analytical Processing in the GPU Era. arXiv:2508.04701 [cs.DB] https://arxiv.org/abs/2508.04701

    arXiv 2025

  62. [63]

    Yogatama, Weiwei Gong, and Xiangyao Yu

    Bobbi W. Yogatama, Weiwei Gong, and Xiangyao Yu. 2022. Orchestrating data placement and query execution in heterogeneous CPU-GPU DBMS.Proc. VLDB Endow.15, 11 (July 2022), 2491–2503. https://doi.org/10.14778/3551793.3551809

    doi:10.14778/3551793.3551809 2022

  63. [64]

    Yichao Yuan, Advait Iyer, Lin Ma, and Nishil Talati. 2025. Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics. Proc. VLDB Endow.18, 4 (May 2025), 1250–1263. https://doi.org/10.14778/3717755. 3717780

    doi:10.14778/3717755 2025

  64. [65]

    Haitao Zhang, Ran Pang, Yuanyuan Zhu, Hao Zhang, Congli Gao, Ming Zhong, Jiawei Jiang, Tieyun Qian, and Jeffrey Xu Yu. 2025. TQEx: Tensor-based Query Engine Enhanced by Bridging the Gap.Proc. ACM Manag. Data3, 6, Article 370 (Dec. 2025), 27 pages. https://doi.org/10.1145/3769835

    work page doi:10.1145/3769835 2025