Pith. sign in

REVIEW 4 major objections 7 minor 1 cited by

GPU Acceleration of SQL Analytics on Compressed Data

T0 review · 4 major / 7 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read GPU SQL analytics can run directly on compressed columns, skipping decompression and beating CPU-only engines on a 2.94-billion-row fact table.

desk verdict Solid systems paper with genuinely new compressed-execution primitives, but the headline order-of-magnitude production claim rests on favorable data ordering and hand-tuned plans that need more disclosure. read the letter →

arxiv 2506.10092 v2 pith:GO4XRIFH submitted 2025-06-11 cs.DB

Zezhou Huang , Krystian Sakowski , Hans Lehnert , Wei Cui , Carlo Curino , Matteo Interlandi , Marius Dumitru , Rathijit Sen This is my paper · ORCID
classification cs.DB
keywords GPUqueryprocessingrun-lengthencodingcompresseddataexecutiontensorprogramsSQLanalyticscolumnarstorageorderingrelationaloperators
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper claims that SQL analytics queries can be run directly on lightweight-compressed data—run-length encoding, index encoding, bit-width reduction, and dictionary encoding—inside a GPU, without first decompressing the columns. The authors build a set of parallel primitives, implemented as tensor operations on a portable runtime, that align runs across multiple compressed columns so that relational operators (selection, join, group-by, aggregation) work in compressed space. The payoff, if the paper is right, is that a single A100 GPU can answer analytics queries over a 2.94-billion-row fact table roughly 10–16 times faster than commercial CPU-only systems, while using less than the 80 GB of GPU memory the same data would need uncompressed. The speedups depend on data ordering that produces long runs, which is why the production dataset is stored in V-order (a sort order that clusters repeated values) and the TPC-H experiments use query-specific sort orders.

What carries the argument

The load-bearing mechanism is the range-intersection primitive (Algorithm 1), which takes two sorted lists of RLE intervals and, using two bucketized binary searches over interval starts and ends, produces the set of overlapping intervals together with index tensors that map each touching input run to the corresponding output runs. This becomes the Alignment step used whenever two compressed columns must be combined: after alignment all columns share the same start and end tensors, so point-wise operations reduce to ordinary tensor arithmetic on the aligned value tensors. Two composite encodings extend the same machinery—Plain+Index isolates outliers to allow narrower bit widths, and RLE+Index covers columns that mix long runs with scattered values—so that the compressed representation can be chosen per column.

What would settle it

Randomly permute the rows of the production fact table (or replace V-order with a hash distribution) and rerun the same three queries; if the 9.8–15.8× speedups over CPU persist, the run-length assumption is not load-bearing. The paper's own skewed TPC-H experiment, where only Q1 improved under V-order, predicts that the speedup would collapse to well under an order of magnitude.

Watch

Extended reading notes

Core claim

The central claim is that a comprehensive SQL query engine can execute end-to-end on a GPU directly on lightweight-compressed columns—run-length encoding, index encoding, bit-width reduction, and dictionary encoding—without expanding runs or decompressing before processing. The obstacle that has kept earlier systems from doing this is run misalignment: runs in two RLE columns rarely share start and end positions, so point-wise operations cannot be performed directly. The paper's solution is an alignment transformation built on a parallel range-intersection primitive: it bucketizes the interval endpoints of one column against the other, then emits a common set of intersection intervals with per-column value tensors duplicated as needed, so that all columns become positionally aligned. Once alignment is achieved, arithmetic, comparisons, boolean masks, semi-join lookups, and scatter-based aggregation all operate on the compressed value and run-length tensors, with cost proportional to the number of runs rather than the number of rows. Experimental evidence shows this reduces peak GPU memory by up to 3.7× on TPC-H and, on a production 2.94-billion-row fact table that does not fit uncompressed, yields 9.8–15.8× speedups over SQL Server and 8.1–13.2× over Analysis Services.

Load-bearing premise

The order-of-magnitude speedup presumes that the table's rows are physically ordered so that repeated values form long runs; without that ordering, RLE compression is weak and the compressed operators can be slower than plain execution.

Editorial extensions

If this is right

  • Large analytics tables that exceed GPU memory can be processed on a single GPU without partitioning or multi-GPU scale-out, provided the storage layout is RLE-friendly; this widens the set of workloads GPU acceleration can reach.
  • Because operators operate on runs rather than rows, query time becomes increasingly insensitive to row count as compression improves, a scaling behavior opposite to that of plain columnar execution.
  • The alignment primitive is a generic building block: any relational operation that must combine two compressed columns (including semi-joins and join-index application) can be assembled from it, so the technique extends beyond the specific queries in the evaluation.
  • The portability of the tensor-based implementation means the same compressed operators can target other accelerators without rewriting the SQL-to-execution stack.
  • For workloads whose data is not already run-length-friendly, the framework's slowdowns on poorly ordered data bound the importance of physical design choices such as V-order or sorted tables in unlocking GPU acceleration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next step, implicit in the paper's heuristic encoding choices, is to make encoding selection and the decision to align versus decompress cost-based inside the optimizer; the microbenchmark showing a 4.29 ms Plain-to-RLE conversion overhead suggests that cross-operator amortization is what would justify such decisions.
  • If the order-of-magnitude results hold, then physical data layout becomes a first-class lever for GPU adoption in analytics: systems that already produce long runs (sorted tables, clustered indexes, time-ordered append-only logs) may need little more than this execution layer to become GPU-accelerated.
  • The same bucketize-based range intersection could be evaluated on CPU vectorized engines; if the performance profile transfers, compressed CPU query processing might also improve on run-length-friendly data, which would generalize the paper's contribution beyond GPUs.
  • The public-BI result—2.02× geometric mean speedup with 10 of 38 queries slowing down—suggests a measurable relationship between average run length and speedup; a focused benchmark varying run length while holding the query fixed would let users predict when compressed GPU execution is worthwhile.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 7 minor

Summary. This paper extends the Tensor Query Processor (TQP) framework to execute SQL analytics queries directly on lightweight-compressed columns (RLE, index encoding, and the composite Plain+Index and RLE+Index encodings) on GPUs, using PyTorch tensor primitives as the portable execution substrate. The technical core is a set of parallel primitives for compressed data (range_intersect, idx_in_rle, idx_in_idx, rle_contain_idx, range_union, complement, compaction, encoding conversions) plus relational operator implementations built on them: logical AND/OR/NOT over compressed masks, run-alignment for arithmetic and comparison across heterogeneous encodings, group-by aggregation over RLE columns, and hash joins with RLE/index-encoded inputs. The evaluation benchmarks against external systems: three production queries on a 2.94B-row fact table report 9.82x-15.75x speedups over SQL Server and 8.05x-13.16x over Analysis Services (Section 9.2.2, Figure 11); at TPC-H SF=100 the compressed GPU execution is 12.8x faster than HeavyDB on average (Section 9.1); and 38 public BI queries show a 2.02x geometric-mean speedup over the paper's own Plain GPU baseline with 10 of 38 queries regressing (Section 9.3). The paper is candid about the conditions: TPC-H uses query-specific sort orders (Appendix B.1), general V-order on skewed TPC-H improves only Q1 (Appendix B.2), and the plans were manually optimized and assume non-NULL data (Appendix D).

Significance. The paper's strengths are real. The algorithms are presented with pseudocode and checked worked examples (Examples 2-4), the appendices give step-by-step walkthroughs of NOT, group-by aggregation, and join-index generation, and the evaluation is anchored to external commercial systems (SQL Server, Analysis Services) rather than being self-referential; the heavy reliance on TQP as the Plain GPU baseline is acceptable because the central claims are tested against other engines. The compression ablation (Figure 9), the memory-capacity analysis (Figures 10 and 19), and the honest reporting of regressions on public BI data (Section 9.3) are exemplary. If the production numbers hold up under reproduction, the paper demonstrates a practically valuable capability: running analytics on compressed data that exceeds GPU HBM, with order-of-magnitude speedups on V-ordered or low-cardinality workloads.

major comments (4)
  1. [Section 9.2.2, Figure 11] The headline claim of 9.82-15.75x speedups over SQL Server and 8.05-13.16x over Analysis Services is not reproducible from the information provided. The paper does not disclose the SQL Server or Analysis Services versions, whether SQL Server used columnstore or rowstore with what compression and batch-mode settings, the MAXDOP or memory configuration, or the SQL text of the three production queries; the warm-up protocol is described only as caches having been warmed (Section 9). Because columnstore batch-mode versus row-mode execution can change SQL Server runtimes by an order of magnitude, these are load-bearing omissions, not presentation details. In addition, the paper reports warm query times averaged over multiple runs without stating the number of runs or any variance, and the GPU times assume data already resident in HBM while the separately measured one-time transfer times (1.29-2.16 s; Section 9.2.1) exceed the per-query GPU runtimes (12-45 ms) by two orders of magnitude; the amortization assumption behind the headline ratio should be stated wherever the order-of-magnitude claim appears.
  2. [Appendix D] The measured GPU numbers were produced by manually optimized query plans, not by the framework automatically. Appendix D states that the plans apply predicates to RLE columns before Plain columns, prioritize RLE join columns, remove redundant filter operations, and - critically - 'exclude NULL handling operators and assume non-NULL data', and that these optimizations 'are currently applied manually'. Because NULL support is acknowledged as missing, the comparison against SQL Server and Analysis Services is not on equal semantic footing if the baselines handle NULLs correctly, and the production speedups characterize hand-written plan rewrites rather than the end-to-end behavior of the proposed system. Sections 9.2.2 and the abstract should state explicitly that the reported numbers include manual plan optimization on non-NULL data, or the authors should provide automatically generated plan baselines for at least the three production queries.
  3. [Section 9.1] The only TPC-H comparison against SQL Server is the sentence 'Using SQL Server query times for SF=50 as reference, the sum of times for the 8 queries running on GPU with compressed data was 12.8x lower for SF=50 and 2.6x lower for SF=300 (6x larger SF)'. This is ambiguous about whether SQL Server was run at each scale factor or only at SF=50, and about what the comparison basis is in each clause. No per-query SQL Server times appear in any figure, and the HeavyDB comparison in Figure 8 covers only SF=100 without reporting HeavyDB's configuration or whether the data fit in the GPU memory available to it. Please report per-query baseline times at each scale factor with the same configuration detail required for Section 9.2.2.
  4. [Abstract; Appendices B.1-B.2; Section 9.3] The order-of-magnitude claim is conditional on data ordering and cardinality structure, and the paper's own experiments bound the general case. With query-agnostic V-order on skewed TPC-H, only Q1 improves (Appendix B.2, Figure 16), and on 38 public BI queries the geometric-mean speedup over the Plain GPU baseline is 2.02x with 10 of 38 queries slowing down by up to 3.13x (Section 9.3). The production speedups rest on a fact table that is already V-ordered by default in Microsoft Fabric and that includes a column consisting of a single 2.94B-row run (Appendix C.2). The abstract's statement that experimental evaluations show 'speedups of an order of magnitude' should be explicitly scoped to V-ordered or query-sorted, low-cardinality data; as written it invites a generalization that the paper's own measurements contradict.
minor comments (7)
  1. [Sections 5.1 and 9] The encoding-selection heuristics (the RLE-to-Plain/Index selectivity threshold, default 20, determined by offline profiling; the RLE compression ratio threshold, >20; and the top/bottom 5% outlier percentile for Plain+Index) are load-bearing for which encodings are chosen, but no sensitivity analysis of end-to-end query times to these thresholds is given; a short discussion would strengthen the robustness claims.
  2. [Section 2.2] The 'Tensor Indexing []' bullet contains an empty bracket pair where the PyTorch documentation reference should be.
  3. [Section 9.1] The phrase '12.8x lower' should read 'a factor of 12.8 faster' (or similar), and the parenthetical '(6x larger SF)' does not make the reference basis clear; this compounds the ambiguity described in Major Comment 3.
  4. [Figure 12] The x-axis labels are unreadably compressed (for example, 'B-1B-2CG-1'), and the query identifiers such as E16-1 and NYC-1 are never defined; a table mapping each identifier to its dataset and query would make the figure interpretable.
  5. [Section 9.2] The SQL text of the three production queries should be provided, at least in fully de-identified form; descriptions such as '7 semi-joins and 2 PK-FK joins' are insufficient for an independent reader to assess query complexity or reproduce the workload.
  6. [Abstract and Section 9.2.2] The phrase 'order of magnitude' in the abstract is slightly stronger than the per-query data support: over SQL Server, Q3 achieves 9.82x, and over Analysis Services Q1 and Q3 achieve 8.72x and 8.05x, all below 10x; the aggregate totals (12.76x and 9.52x) support the claim only when the three queries are summed.
  7. [Section 4, Table 1] Only the intersection primitives receive pseudocode; the paper notes the space limitation, but range_union, merge_sorted_idx, the complement operations, and the conversion primitives are described only in one-line table entries and brief prose. Since these underpin the OR and join implementations, algorithmic descriptions (even in the appendix) would improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the headline speedups are benchmarked against external CPU systems (SQL Server, Analysis Services, HeavyDB), and the TQP self-citations provide background/baseline infrastructure rather than a load-bearing derivation.

full rationale

The paper's central performance claim (Section 9.2.2, Figure 11) is an experimental comparison against external commercial systems: Microsoft SQL Server and Analysis Services on CPUs, plus HeavyDB for TPC-H. Speedups are therefore not constructed from the paper's own assumptions or fitted parameters; they are externally falsifiable measurements. The TQP self-citations (refs [7,18,19], Section 2.1) supply the prior tensor-program execution substrate and the Plain-data baseline, and the paper explicitly states that the Plain baseline is an optimized version of TQP. This is a normal use of prior work, not a circular reduction: the compressed-data operators, the direct-on-RLE execution, and the order-of-magnitude comparison to commercial CPU engines do not depend on accepting TQP's correctness as a premise. No uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in by citation; the encoding choices (RLE, Index, Plain+Index, RLE+Index) are defined in the paper itself (Section 3) and their operators are implemented from stated PyTorch primitives. The Appendix D admission that GPU plans are manually optimized, including removing NULL handling, is a reproducibility and fairness limitation rather than a circularity: it affects whether the reported production speedups can be independently replicated, but it does not make any prediction equivalent to its inputs by construction. Similarly, the use of query-specific sort orders (Appendix B.1) and V-order data (Section 9.2) exposes a workload assumption about run-length compressibility, but the experiments disclose this dependence and the public BI results (Section 9.3) provide an independent, less favorable check (2.02x geometric mean, 10 of 38 queries slower). The paper's derivation chain is self-contained: algorithms are specified in pseudocode, and performance claims rely on measured comparisons rather than on a self-referential fit.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central performance claim depends heavily on the availability of ordered data and on a NULL-free assumption; both are stated but the ordering dependence is only discussed in the appendices, while the NULL limitation is relegated to Appendix D. The PyTorch primitives and sorted-position invariants are reasonable background assumptions. No new entities are introduced.

free parameters (3)
  • RLE-to-Plain/Index selectivity threshold = 20
    Used in AND/OR for RLE mask OR Plain mask: if total elements / selected elements exceeds 20, convert RLE to Index; otherwise to Plain. Determined through offline profiling on the test GPU (Section 5.1).
  • RLE compression ratio threshold = 20
    Column encoding heuristic: use RLE only if compression ratio > 20, otherwise try RLE+Index if many single-element runs, then Plain+Index if outliers allow a narrower type, else Plain (Section 9).
  • Outlier percentile for Plain+Index = top/bottom 5%
    Columns are considered for Plain+Index if removing the top and bottom 5% of values permits a narrower tensor type (Section 9).
assumptions (5)
  • standard math PyTorch primitives (bucketize, repeat_interleave, arange, scatter, unique) are correct and performant on the target GPU backends.
    The compressed operators are built entirely from these library functions (Section 2.2); any semantic mismatch would propagate to all operators.
  • domain assumption Equi-join correctness can be decided on RLE/Index value tensors, with row positions reconstructed by expanding run lengths.
    Section 8.1 hashes the compressed value tensors and maps run indices back to rows via start/end ranges; this assumes no value collisions or ordering effects break the mapping.
  • domain assumption Data ordering that produces long runs is available for the target workloads.
    TPC-H uses query-specific sort orders (Appendix B.1) and the production dataset is V-ordered in Microsoft Fabric (Section 9.2). Appendix B.2 shows that without query-specific ordering, only Q1 improves.
  • domain assumption Input columns contain no NULL values.
    Appendix D states query plans exclude NULL handling and assume non-NULL data, which is required for the reported production query semantics.
  • domain assumption Runs in RLE and positions in Index are non-overlapping and sorted by position, and RLE runs may be contiguous (start_{i+1} >= end_i + 1).
    The intersection algorithms (Algorithms 1-5) rely on sorted position-explicit encodings; Section 3.1 defines these invariants.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GPU Acceleration of SQL Analytics on Compressed Data." pith.science (2026). https://pith.science/paper/GO4XRIFH

@misc{pith2026250610092,
  author       = {Pith},
  title        = {Pith review of: GPU Acceleration of SQL Analytics on Compressed Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GO4XRIFH}},
  note         = {Machine review of arXiv:2506.10092}
}
read the original abstract

GPUs are uniquely suited to accelerate (SQL) analytics workloads thanks to their massive compute parallelism and High Bandwidth Memory (HBM) -- when datasets fit in the GPU HBM, performance is unparalleled. Unfortunately, GPU HBMs remain typically small when compared with lower-bandwidth CPU main memory. Besides brute-force scaling across many GPUs, current solutions to accelerate queries on large datasets include leveraging data partitioning and loading smaller data batches in GPU HBM, and hybrid execution with a connected device (e.g., CPUs). Unfortunately, these approaches are exposed to the limitations of lower main memory and host-to-device interconnect bandwidths, introduce additional I/O overheads, or incur higher costs. This is a substantial problem when trying to scale adoption of GPUs on larger datasets. Data compression can alleviate this bottleneck, but to avoid paying for costly decompression/decoding, an ideal solution must include computation primitives to operate directly on data in compressed form. This is the focus of our paper: a set of new methods for running queries directly on light-weight compressed data using schemes such as Run-Length Encoding (RLE), index encoding, bit-width reductions, and dictionary encoding. Our novelty includes operating on multiple RLE columns without decompression, handling heterogeneous column encodings, and leveraging PyTorch tensor operations for portability across devices. Experimental evaluations show speedups of an order of magnitude compared to state-of-the-art commercial CPU-only analytics systems, for real-world queries on a production dataset that would not fit into GPU memory uncompressed. This work paves the road for GPU adoption in a much broader set of use cases, and it is complementary to most other scale-out or fallback mechanisms.

Figures

Figures reproduced from arXiv: 2506.10092 by the authors.

Figure 1
Figure 1. GPU-Optimized Tensor Data Representations. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Illustration of range_intersect algorithm for AND [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. CPU vs GPU performance for RLE primitives. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (14 more)
Figure 4
Figure 4. Figure 4: Performance comparison of alternative AND de [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Illustration of join operation execution for the [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Total # of runs and average run lengths for fact table [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Peak GPU memory usage (top) and query run times (bottom) for TPC-H queries on Plain and Compressed input data [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: TPC-H query runtime between HeavyDB and com [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Query runtime degradation as compression ratio [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 12
Figure 12. Figure 12: Query runtime for public BI datasets, comparing [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]
Figure 13
Figure 13. Figure 13: Illustration of NOT logical operator. Example 7. Consider applying the NOT operator to the three dif￾ferent mask representations shown in [PITH_FULL_IMAGE:figures/full_fig_p015_13.png]
Figure 14
Figure 14. Figure 14: RLE-compressed data Group-by Aggregation: [PITH_FULL_IMAGE:figures/full_fig_p015_14.png]
Figure 16
Figure 16. Figure 16: TPC-H query run times with skewed data (z=1) at [PITH_FULL_IMAGE:figures/full_fig_p016_16.png]
Figure 15
Figure 15. Figure 15: Illustration of computing Join Indices between [PITH_FULL_IMAGE:figures/full_fig_p016_15.png]
Figure 17
Figure 17. Figure 17: Total number of runs and average run lengths [PITH_FULL_IMAGE:figures/full_fig_p017_17.png]
Figure 18
Figure 18. Figure 18: Run times for production queries, using A100 GPU, on Plain and Compressed data for different table sizes. [PITH_FULL_IMAGE:figures/full_fig_p018_18.png]
Figure 19
Figure 19. Figure 19: Peak GPU memory used and projected for production queries on Plain and Compressed data for different table sizes. [PITH_FULL_IMAGE:figures/full_fig_p018_19.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Eiger: An Efficient Library for GPU-based Data Analytics

    cs.DB 2026-07 accept novelty 6.0 of 10

    Eiger improves single-GPU relational query performance over cuDF by up to 1.8× total (6.1× per query) via multiple operator variants selected by lightweight runtime statistics.

Reference graph

Works this paper leans on

55 extracted references · 37 canonical work pages · cited by 1 Pith paper

  1. [1]

    Arrow Columnar Format: Run-End Encoded Layout

    2025 (last accessed). Arrow Columnar Format: Run-End Encoded Layout. [On- line] Available from: https://arrow.apache.org/docs/format/Columnar.html#run- end-encoded-layout

    work page 2025

  2. [2]

    2025 (last accessed). Vortex. [Online] Available from: https://github.com/spiraldb/ vortex

    work page 2025

  3. [3]

    Daniel Abadi, Peter Boncz, and Stavros Harizopoulos. 2013. The Design and Implementation of Modern Column-Oriented Database Systems . Now Publishers Inc., Hanover, MA, USA

    work page 2013

  4. [4]

    Daniel Abadi, Samuel Madden, and Miguel Ferreira. 2006. Integrating Compres- sion and Execution in Column-Oriented Database Systems. In Proceedings of the 2006 ACM SIGMOD International Conference on Management of Data (Chicago, IL, USA) (SIGMOD ’06). Association for Computing Machinery, New York, NY, USA, 671–682. https://doi.org/10.1145/1142473.1142548

    arXiv 2006

  5. [5]

    Azim Afroozeh and Peter Boncz. 2023. The FastLanes Compression Layout: Decoding > 100 Billion Integers per Second with Scalar Code. PVLDB 16, 9 (May 2023), 2132–2144. https://doi.org/10.14778/3598581.3598587

    arXiv 2023

  6. [7]

    Yuki Asada, Victor Fu, Apurva Gandhi, Advitya Gemawat, Lihao Zhang, Dong He, Vivek Gupta, Ehi Nosakhare, Dalitso Banda, Rathijit Sen, and Matteo Interlandi

  7. [8]

    BlazingSQL. 2021. BlazingSQL. https://github.com/BlazingDB/blazingsql

    work page 2021

  8. [9]

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

    arXiv 2023

Show all 55 references
  1. [10]

    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

    2019

  2. [11]

    Wei Cui, Qianxi Zhang, Spyros Blanas, Jesús Camacho-Rodríguez, Brandon Haynes, Yinan Li, Ravi Ramamurthy, Peng Cheng, Rathijit Sen, and Matteo Interlandi. 2023. Query Processing on Gaming Consoles. In Proceedings of the 19th International Workshop on Data Management on New Har...

    2023

  3. [12]

    Patrick Damme, Annett Ungeth"um, Johannes Pietrzyk, Alexander Krause, Dirk Habich, and Wolfgang Lehner. 2020. Morphstore: Analytical query engine with a holistic compression-enabled processing model. arXiv preprint arXiv:2004.09350 (2020)

    2020 arXiv

  4. [13]

    (last accessed) 2025

    Voltron Data. (last accessed) 2025. Theseus The Enterprise SQL Engine. https: //voltrondata.com/

    2025

  5. [14]

    Augustus De Morgan. 1847. Formal Logic: Or, The Calculus of Inference, Necessary and Probable. Taylor and Walton, London

  6. [15]

    Yangshen Deng, Shiwen Chen, Zhaoyang Hong, and Bo Tang. 2024. How Does Software Prefetching Work on GPU Query Processing?. In Proceedings of the 20th International Workshop on Data Management on New Hardware (Santiago, AA, Chile) (DaMoN ’24). Association for Computing Machiner...

    2024

  7. [16]

    Wenbin Fang, Bingsheng He, and Qiong Luo. 2010. Database compression on graphics processors. Proceedings of the VLDB Endowment 3, 1-2 (2010), 670–680

    2010

  8. [17]

    Apache Software Foundation. 2021. Apache Parquet. https://parquet.apache.org/ Accessed: 2025-03-25

    2021

  9. [18]

    Apurva Gandhi, Yuki Asada, Victor Fu, Advitya Gemawat, Lihao Zhang, Rathijit Sen, Carlo Curino, Jesús Camacho-Rodríguez, and Matteo Interlandi. 2022. The Tensor Data Platform: Towards an AI-centric Database System. In CIDR

    2022

  10. [19]

    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 Runtimes. PVLDB (2022), 2811–2825

    2022

  11. [20]

    2025 (last accessed)

    HeavyDB. 2025 (last accessed). HeavyDB. https://github.com/heavyai/heavydb

    2025

  12. [21]

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

    2025

  13. [23]

    Chien, Jihong Ma, and Aaron J

    Hao Jiang, Chunwei Liu, John Paparrizos, Andrew A. Chien, Jihong Ma, and Aaron J. Elmore. 2021. Good to the Last Bit: Data-Driven Encoding with CodecDB. In Proceedings of the 2021 International Conference on Management of Data(Virtual Event, China) (SIGMOD ’21). Association fo...

    2021

  14. [24]

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

    2015

  15. [25]

    Maximilian Kuschewski, David Sauerwein, Adnan Alhomssi, and Viktor Leis

  16. [26]

    Ryan M Layer, Kevin Skadron, Gabriel Robins, Ira M Hall, and Aaron R Quin- lan. 2013. Binary Interval Search: a scalable algorithm for counting interval intersections. Bioinformatics 29, 1 (2013), 1–7

    2013

  17. [27]

    Jae-Gil Lee, Guy Lohman, Konstantinos Morfonios, Keshava Murthy, Ippokratis Pandis, Lin Qiao, Vijayshankar Raman, Vincent Kulandai Samy, Richard Sidle, Knut Stolze, et al. 2014. Joins on encoded and partitioned data. Proceedings of the VLDB Endowment (2014)

    2014

  18. [28]

    Jing Li, Hung-Wei Tseng, Chunbin Lin, Yannis Papakonstantinou, and Steven Swanson. 2016. HippogriffDB: balancing I/O and GPU bandwidth in big data analytics. PVLDB 9, 14 (Oct. 2016), 1647–1658. https://doi.org/10.14778/3007328. 3007331

    2016 doi

  19. [29]

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

  20. [30]

    Tobias Maltenberger, Ivan Ilic, Ilin Tolovski, and Tilmann Rabl. 2022. Evaluating Multi-GPU Sorting with Modern Interconnects. In Proceedings of the 2022 Inter- national Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22). Association for Computing Machinery,...

    2022

  21. [31]

    Wes McKinney. 2010. Data structures for statistical computing in python. In Proceedings of the 9th Python in Science Conference , Vol. 445. 51–56

    2010

  22. [32]

    Microsoft. 2024. Dv5 sizes series. https://learn.microsoft.com/en-us/azure/ virtual-machines/sizes/general-purpose/dv5-series

    2024

  23. [33]

    Microsoft. 2024. NC_A100_v4 sizes series. https://learn.microsoft.com/en- us/azure/virtual-machines/sizes/gpu-accelerated/nca100v4-series

    2024

  24. [34]

    Microsoft. 2024. Understand V-Order for Microsoft Fabric Warehouse. [On- line] Available from: https://learn.microsoft.com/en-us/fabric/data-warehouse/v- order

    2024

  25. [35]

    Microsoft. 2025. What is Analysis Services? [Online] Available from: https://learn.microsoft.com/en-us/analysis-services/analysis-services- overview?view=asallproducts-allversions

    2025

  26. [36]

    Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gre- gory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, L...

    2019

  27. [37]

    Johns Paul, Shengliang Lu, and Bingsheng He. 2021. Database Systems on GPUs . Now Foundations and Trends

    2021

  28. [38]

    Viktor Rosenfeld, Sebastian Breß, and Volker Markl. 2022. Query processing on heterogeneous CPU/GPU systems. ACM Computing Surveys (CSUR) 55, 1 (2022), 1–38

    2022

  29. [39]

    Ran Rui, Hao Li, and Yi-Cheng Tu. 2020. Efficient Join Algorithms for Large Database Tables in a Multi-GPU Environment. Proc. VLDB Endow. 14, 4 (dec 2020), 708–720. https://doi.org/10.14778/3436905.3436927

    2020

  30. [40]

    Ran Rui and Yi-Cheng Tu. 2017. Fast Equi-Join Algorithms on GPUs: Design and Implementation. In Proceedings of the 29th International Conference on Scientific and Statistical Database Management (Chicago, IL, USA)(SSDBM ’17). Association for Computing Machinery, New York, NY, ...

    2017

  31. [41]

    Anil Shanbhag, Samuel Madden, and Xiangyao Yu. 2020. A Study of the Funda- mental Performance Characteristics of GPUs and CPUs for Database Analytics. In SIGMOD. 1617–1632

    2020

  32. [42]

    Yogatama, Xiangyao Yu, and Samuel Madden

    Anil Shanbhag, Bobbi W. Yogatama, Xiangyao Yu, and Samuel Madden. 2022. Tile-based Lightweight Integer Compression in GPU. In Proceedings of the 2022 International Conference on Management of Data (Philadelphia, PA, USA) (SIG- MOD ’22). Association for Computing Machinery, New...

    2022

  33. [43]

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

    2019

  34. [44]

    Evangelia Sitaridi. 2016. GPU-acceleration of in-memory data analytics . Columbia University

    2016

  35. [45]

    Jim Stam. 2022. Low overhead self-optimizing storage for compression in DuckDB . Master’s thesis. Universiteit van Amsterdam–Vrije Universiteit Amsterdam. 13

    2022

  36. [46]

    Oliphant Travis E. 2006. NumPy. http://www.numpy.org/

    2006

  37. [47]

    Adrian Vogelsgesang, Michael Haubenschild, Jan Finis, Alfons Kemper, Viktor Leis, Tobias Mühlbauer, Thomas Neumann, and Manuel Then. 2018. Get real: How benchmarks fail to represent the real world. In Proceedings of the Workshop on Testing Database Systems. 1–6

    2018

  38. [48]

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

    2025 doi

  39. [49]

    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

    2025

  40. [50]

    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

    2022

  41. [51]

    Yichao Yuan, Advait Iyer, Lin Ma, and Nishil Talati. 2025. Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics. arXiv:2502.09541 [cs.DB] https://arxiv.org/abs/2502.09541

    2025 arXiv

  42. [52]

    Yuan Yuan, Rubao Lee, and Xiaodong Zhang. 2013. The Yin and Yang of Pro- cessing Data Warehousing Queries on GPU Devices. In Proceedings of the VLDB Endowment (PVLDB), Vol. 6. 817–828

    2013

  43. [53]

    Xin, Patrick Wendell, Tathagata Das, Michael Armbrust, Ankur Dave, Xiangrui Meng, Josh Rosen, Shivaram Venkataraman, Michael J

    Matei Zaharia, Reynold S. Xin, Patrick Wendell, Tathagata Das, Michael Armbrust, Ankur Dave, Xiangrui Meng, Josh Rosen, Shivaram Venkataraman, Michael J. Franklin, Ali Ghodsi, Joseph Gonzalez, Scott Shenker, and Ion Stoica. 2016. Apache Spark: a unified engine for big data pro...

    2016 doi

  44. [54]

    SELECT SUM(B) GROUP BY A

    Marcin Zukowski, Sandor Heman, Niels Nes, and Peter Boncz. 2006. Super- scalar RAM-CPU cache compression. In 22nd International Conference on Data Engineering (ICDE’06). IEEE, 59–59. 14 A OPERATOR IMPLEMENTATION DETAILS AND EXAMPLES This section provides detailed algorithmic i...

    2006

  45. [2020]

    In Proceedings 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. In Proceedings 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....

    2020 doi

  46. [2022]

    PVLDB (2022), 3598–3601

    Share the tensor tea: how databases can leverage the machine learning ecosystem. PVLDB (2022), 3598–3601

    2022

  47. [2023]

    In Proceed- ings of the 2023 ACM SIGMOD International Conference on Management of Data (SIGMOD ’23)

    BtrBlocks: Efficient Columnar Compression for Data Lakes. In Proceed- ings of the 2023 ACM SIGMOD International Conference on Management of Data (SIGMOD ’23). 2205–2217

    2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.