pith. sign in

arxiv: 1907.00050 · v1 · pith:ENWB6T67new · submitted 2019-06-27 · 💻 cs.DC · cs.DB· cs.PF

State-of-the-Art on Query & Transaction Processing Acceleration

Bernd Amann , Youry Khmelevsky , Gaetan Hains This is my paper

Pith reviewed 2026-05-25 14:55 UTC · model grok-4.3

classification 💻 cs.DC cs.DBcs.PF
keywords GPU accelerationdatabase management systemsquery processingtransaction processingco-processorsarchitectural challengesstate of the art
0
0 comments X

The pith

GPUs can accelerate database query and transaction processing but require adaptations that leave major architectural challenges open.

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

The report reviews how modern GPUs have been explored as co-processors for data-intensive database tasks due to their processing power and memory bandwidth. It outlines key properties of GPU-aware database architectures along with the typical challenges that arise when integrating GPUs at different system levels. Drawing on prior cited work, the report identifies major open challenges and possible directions for further investigation. A reader would care because overcoming these issues could allow databases to make fuller use of GPU hardware for faster handling of queries and transactions.

Core claim

The database community has explored GPUs as effective co-processors for data processing, resulting in approaches at various levels of database systems. GPU-aware database architectures exhibit distinct key properties and typical challenges, and the survey identifies the major open challenges that remain to be addressed.

What carries the argument

GPU-aware database architectures, which treat GPUs as co-processors integrated at multiple levels for accelerating query and transaction processing.

If this is right

  • Database designs that incorporate GPUs must address the listed key properties and typical challenges to realize performance gains.
  • Future work can focus on resolving the identified major open challenges in GPU-accelerated query and transaction processing.
  • Integration of GPU co-processing can occur at multiple levels within a database system architecture.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The identified challenges could guide prioritization of development efforts toward specific integration points in database software.
  • Resolving the challenges may enable broader adoption of GPUs in production database environments beyond research prototypes.
  • Similar co-processor strategies might apply to other data-intensive domains that share memory-bandwidth constraints.

Load-bearing premise

The referenced prior works supply a sufficient and accurate basis for identifying the current challenges in GPU-accelerated DBMS.

What would settle it

A later survey that documents a substantially different set of major open challenges in GPU-accelerated database systems would show the identification here to be incomplete.

read the original abstract

The vast amount of processing power and memory bandwidth provided by modern Graphics Processing Units (GPUs) make them a platform for data-intensive applications. The database community identified GPUs as effective co-processors for data processing. In the past years, there were many approaches to make use of GPUs at different levels of a database system. In this Internal Technical Report, based on the [1] and some other research papers, we identify possible research areas at LIP6 for GPU-accelerated database management systems. We describe some key properties, typical challenges of GPU-aware database architectures, and identify major open challenges.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

0 major / 1 minor

Summary. The manuscript is an internal technical report surveying GPU use for accelerating query and transaction processing in database management systems. Based on [1] and other cited papers, it describes key properties and typical challenges of GPU-aware database architectures and identifies major open challenges along with possible research areas at LIP6.

Significance. If the summaries of prior work are accurate, the report could serve as a useful internal reference for directing GPU-DBMS research at LIP6 by consolidating known challenges. As a descriptive literature review without new empirical results, derivations, or quantitative claims, its broader significance for the field is modest and depends entirely on the fidelity of the cited sources.

minor comments (1)
  1. [Abstract] Abstract: the reference [1] is mentioned but not expanded with full bibliographic details (authors, title, venue, year); this should be supplied so readers can locate the foundational source.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the careful reading and positive recommendation to accept our internal technical report. The report is intended as a consolidation of known challenges for directing GPU-DBMS research at LIP6 rather than a contribution with new empirical results.

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is an internal technical report and literature review that explicitly frames its content as a summary 'based on [1] and some other research papers.' It identifies research areas, describes properties and challenges, but advances no derivations, equations, predictions, fitted parameters, or quantitative claims. No load-bearing steps exist that could reduce to self-definition, fitted inputs, or self-citation chains. The central claim is the act of identification itself, which holds independently of the accuracy of the cited summaries.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

As a literature review the report introduces no free parameters, axioms, or invented entities; all content is drawn from the referenced prior publications.

pith-pipeline@v0.9.0 · 5630 in / 974 out tokens · 20256 ms · 2026-05-25T14:55:57.769544+00:00 · methodology

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

15 extracted references · 15 canonical work pages

  1. [1]

    S. Breß, M. Heimel, N. Siegmund, L. Bellatreche, and G. Saake, GPU-Accelerated Database Sys- tems: Survey and Open Challenges , pp. 1–35. Berlin, Heidelberg: Springer Berlin Heidelberg, 2014

    work page 2014

  2. [2]

    The future of microprocessors,

    S. Borkar and A. A. Chien, “The future of microprocessors,” Commun. ACM, vol. 54, pp. 67–77, May 2011

    work page 2011

  3. [3]

    Weaving relations for cache perfor- mance,

    A. Ailamaki, D. J. DeWitt, M. D. Hill, and M. Skounakis, “Weaving relations for cache perfor- mance,” in Proceedings of the 27th International Conference on Very Large Data Bases , VLDB ’01, (San Francisco, CA, USA), pp. 169–180, Morgan Kaufmann Publishers Inc., 2001

    work page 2001

  4. [4]

    Accelerating sql database operations on a GPU with CUDA,

    P. Bakkum and K. Skadron, “Accelerating sql database operations on a GPU with CUDA,” in Proceedings of the 3rd Workshop on General-Purpose Computation on Graphics Processing Units , GPGPU-3, (New York, NY, USA), pp. 94–103, ACM, 2010

    work page 2010

  5. [5]

    Relational query coprocessing on graphics processors,

    B. He, M. Lu, K. Yang, R. Fang, N. K. Govindaraju, Q. Luo, and P. V. Sander, “Relational query coprocessing on graphics processors,” ACM Trans. Database Syst. , vol. 34, pp. 21:1–21:39, Dec. 2009

    work page 2009

  6. [6]

    Revisiting co-processing for hash joins on the coupled CPU-GPU architecture,

    J. He, M. Lu, and B. He, “Revisiting co-processing for hash joins on the coupled CPU-GPU architecture,” Proc. VLDB Endow. , vol. 6, pp. 889–900, Aug. 2013

    work page 2013

  7. [7]

    Waste not. . . efficient co-processing of relational data,

    H. Pirk, S. Manegold, and M. Kersten, “Waste not. . . efficient co-processing of relational data,” in 2014 IEEE 30th International Conference on Data Engineering , pp. 508–519, March 2014

    work page 2014

  8. [8]

    Palo GPU accelerator,

    “Palo GPU accelerator,” white paper, 2010

    work page 2010

  9. [9]

    Parstream — turning data into knowledge,

    “Parstream — turning data into knowledge,” white paper, November 2010

    work page 2010

  10. [10]

    R. Fang, B. He, M. Lu, K. Yang, N. K. Govindaraju, Q. Luo, and P. V. Sander, “GPUQP: Query co-processing using graphics processors, url = http://doi.acm.org/10.1145/1247480.1247606, year = 2007, bdsk-url-1 = http://doi.acm.org/10.1145/1247480.1247606, bdsk-url-2 = https://doi.org/10.1145/1247480.1247606,” in Proceedings of the 2007 ACM SIGMOD Interna- tio...

    work page doi:10.1145/1247480.1247606 2007

  11. [11]

    Gaster, L

    B. Gaster, L. Howes, D. R. Kaeli, P. Mistry, and D. Schaa, Heterogeneous computing with openCL: revised openCL 1. Newnes, 2012

    work page 2012

  12. [12]

    NVIDIA CUDA C programming guide,

    NVIDIA, “NVIDIA CUDA C programming guide,” September 2018

    work page 2018

  13. [13]

    Analyzing the energy efficiency of a database server,

    D. Tsirogiannis, S. Harizopoulos, and M. A. Shah, “Analyzing the energy efficiency of a database server,” in Proceedings of the 2010 ACM SIGMOD International Conference on Management of Data, SIGMOD ’10, (New York, NY, USA), pp. 231–242, ACM, 2010

    work page 2010

  14. [14]

    Relational joins on graphics processors,

    B. He, K. Yang, R. Fang, M. Lu, N. Govindaraju, Q. Luo, and P. Sander, “Relational joins on graphics processors,” in Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data , SIGMOD ’08, (New York, NY, USA), pp. 511–524, ACM, 2008

    work page 2008

  15. [15]

    Toward hardware-sensitive database opera- tions.,

    D. Broneske, S. Breß, M. Heimel, and G. Saake, “Toward hardware-sensitive database opera- tions.,” in EDBT, pp. 229–234, 2014. Technical Report CSI-PARIS-TR-2018-10 7 Huawei unclassified

    work page 2014