Pith. sign in

REVIEW 2 major objections 5 minor 38 references

Global Hash Tables Strike Back! An Analysis of Parallel GROUP BY Aggregation

T0 review · 2 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read Fully concurrent GROUP BY using a single purpose-built hash table can match or beat partitioning-based aggregation in morsel-driven engines when the table is specialized for the lookup-and-insert ticketing workload.

desk verdict A well-executed experimental study showing purpose-built shared hash tables can match partitioned GROUP BY, but the perfect-cardinality-estimation assumption makes the practical claim conditional. read the letter →

arxiv 2505.04153 v2 pith:RUMZ6BTD submitted 2025-05-07 cs.DB

Daniel Xue , Ryan Marcus This is my paper · ORCID
classification cs.DB
keywords groupbyaggregationparallelqueryprocessingconcurrenthashtablelinearprobingticketingpartitionedmorsel-drivenexecutionOLAP
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

Parallel GROUP BY in modern analytic databases is usually done by partitioning the input so each thread processes only its own keys, which adds a second aggregation pass and more memory. This paper argues that a simpler alternative—a single shared hash table used by all threads—has been wrongly dismissed because it was implemented with general-purpose concurrent hash tables, which carry deletes, shrinking, and mixed-workload support that aggregation never needs. The authors build a purpose-built, lock-free linear-probing table with an atomic get-or-insert 'ticketing' operation and show that, in a morsel-driven execution engine, it matches or beats partitioning across synthetic workloads of different cardinality and skew, with a heavy-hitter extreme as the main exception. They also provide a practical characterisation of the remaining design choices: atomic partial-aggregate updates for high-cardinality inputs, thread-local updates for skewed inputs, capped thread counts for the thread-local variant, and the continued importance of accurate cardinality estimation to avoid costly resizing.

What carries the argument

The central object is the Folklore* hash table: a lock-free linear-probing hash table that supports only a single atomic get-or-insert operation, in which a key is looked up and, if absent, assigned an integer ticket via a one-word compare-and-swap on a pre-reserved slot state. A 'fuzzy ticketer' gives each thread a private range of ticket values so the shared counter is only touched when a range is exhausted, and zero-allocation (calloc-style) defers table initialization so allocation leaves the single-threaded critical path. Tickets index a dense vector of partial aggregates, which are updated either atomically or in per-thread vectors; the table also stores a copy of keys in ticket order for final materialization. This combination reduces the concurrent data structure's job to the minimal lookup-and-insert workload that group aggregation actually requires.

What would settle it

Run an end-to-end comparison on the paper's own high-cardinality dataset (10 million unique keys, SUM) at 48 threads while forcing the fully concurrent implementation to start with a hash table sized at one-quarter of the true cardinality, forcing multiple resizes, and measure whether the fully concurrent method still matches partitioned aggregation; a decisive slowdown would show the central claim holds only under the paper's perfect-sizing assumption.

Watch

Extended reading notes

Core claim

The paper's central claim is that the long-standing verdict against shared-hash-table aggregation stems from using general-purpose concurrent hash tables, which must support deletes, shrinking, and mixed workloads; a table written only for the lookup-and-insert pattern of group aggregation removes the scalability barrier. Concretely, the authors show that their Folklore* linear-probing table, paired with a fuzzy ticket counter and zero-allocation, achieves a 37.6x speedup on low-cardinality workloads at 48 threads and, end-to-end, a fully concurrent implementation reaches parity or beats the partitioned baseline on synthetic workloads, with a heavy-hitter extreme as the notable exception. They also document the operational tradeoffs: atomic updates win when keys are unique, thread-local updates win under skew, and resizing remains the weak spot.

Load-bearing premise

The claimed advantage assumes the database knows the number of distinct keys ahead of time so the hash table and partial aggregate vectors are allocated at exactly the right size; in the forced-resize test at half capacity, latency rises by up to 5.2x in the unique-keys case, so the practical viability claim depends on accurate cardinality estimates.

Editorial extensions

If this is right

  • A database engine can implement parallel GROUP BY with a single shared hash table instead of partitioning, eliminating the second aggregation pass and the associated spilling and memory overhead in many workloads.
  • Per-query choice of update method matters: atomic updates win on high-cardinality, unique-key inputs, while thread-local updates win under skew and low cardinality; the paper's measurements quantify when each should be selected.
  • Implementers should cap the thread count for thread-local updates to avoid inverse scaling from the materialization merge, and should prefer zero-allocation for large hash tables to keep allocation off the single-threaded path.
  • Resizing is the main remaining weakness: with tables sized at half the required capacity, end-to-end latency rises by up to 5.2x for unique keys, so accurate cardinality estimation is a prerequisite for the approach's practical viability.

Reading between the lines

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

  • Viewing ticketing as incremental perfect hashing suggests that offline perfect hash functions, already proposed for OLAP aggregation, could eliminate ticketing contention entirely—an extension the paper names but does not implement.
  • A hybrid update strategy, using thread-local aggregation for heavy hitters and atomic updates for the rest, would likely close the heavy-hitter gap that is the paper's clearest exception; such hybrids already exist in the aggregation literature.
  • The paper's results were obtained under perfect cardinality estimation; feeding the same implementation with the estimation errors of a real optimizer would be a natural stress test and could change the recommended operating region.
  • Because the benchmark uses only morsel-driven execution, the conclusions may not transfer to operator-level or pipeline-parallel engines, where the thread-to-data assignment and synchronization patterns differ.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 5 minor

Summary. The paper revisits fully concurrent hash-based GROUP BY aggregation, where a shared global hash table maps each key to a ticket that indexes a vector of partial aggregates, and compares it against the partitioned aggregation approach with local preaggregation used in morsel-driven engines. The authors evaluate several concurrent hash table designs for the ticketing step, compare atomic, locking, and thread-local update methods, and then report end-to-end scaling experiments on AMD, ARM, and Intel platforms across low, high, and unique cardinality datasets with skew variants, along with profiling, resizing, memory, and tuple-size analyses. The main claim is that a simple purpose-built linear-probing hash table with a customized atomic get-or-insert operation makes fully concurrent aggregation competitive with, and often faster than, partitioning-based aggregation, except in the acknowledged heavy-hitter regime where the partitioned baseline retains an advantage.

Significance. If the stated results hold, the paper provides a concrete, implementable alternative to partitioned GROUP BY aggregation, with useful practical guidance: linear probing suffices for the ticketing workload, lockless fast paths are essential, a fuzzy ticket counter avoids atomic-counter contention, and thread-local updates are robust under skew but memory-hungry at high thread counts. The study is extensive and well-designed in several respects: it covers three architectures, uses top-down profiling and performance counters, includes resizing and peak-memory analyses, and makes the source code and artifacts available. The paper is also careful to acknowledge exceptions (e.g., heavy hitters at high thread counts) and to present its conclusions in a balanced way. The main weakness is that the overarching practical-viability claim depends on an assumption of perfect cardinality estimation, and the paper's single robustness test for this assumption shows a large performance penalty in the worst case.

major comments (2)
  1. [§2.4, §4.5] The central claim that fully concurrent aggregation is a viable alternative to partitioning rests on the assumption, stated in Section 2.4, that all end-to-end experiments except Section 4.5 assume perfect cardinality estimation and therefore perfectly sized hash tables and partial aggregate vectors. Section 4.5, the only robustness test, forces a single resize by allocating the ticketing table at half the required capacity. The resulting latency increase is substantial: a 5.2x slowdown for unique keys with atomic updates and 2.0x for thread-local updates at 48 threads (Figure 13). Because the paper does not report the resized configuration against the partitioned baseline, the unique-key advantage visible in Figure 7 is not known to survive this penalty. Real cardinality estimates after filters, joins, and on skewed data are often off by more than a factor of two, and larger underestimates would trigger multiple resizes, which Section 4.5 does not test. The manuscript labels resizing as future work, but the stated conclusion that fully concurrent aggregation is a viable alternative requires either experimentally demonstrated resize costs or a scoping of the claim to workloads with accurate cardinality estimates. This is a load-bearing condition, not a cosmetic caveat.
  2. [§3.2, §4.1] The paper's recommendation to choose the update method adaptively based on the number of unique keys (Section 3.2, Table 2) is derived from experiments that assume exact cardinality knowledge: the isolated update benchmarks in Section 3.2 use a perfect hash function (ticket = key), and the end-to-end experiments in Section 4.1 assume perfectly sized structures. The practical guidelines in the 'Recommendations' paragraph of Section 4.1 therefore presume that the optimizer's cardinality estimate is reliable. The paper does not evaluate how estimation error affects the choice between atomic and thread-local updates, nor how the 5.2x resize penalty interacts with the switch between methods. Without such an evaluation, the adaptive-guidance claim is only as strong as the perfect-estimation assumption. I would ask the authors to either test the adaptive policy under noisy cardinality estimates or explicitly restrict the guidelines to settings where cardinality estimates are known to be accurate.
minor comments (5)
  1. [Algorithm 1] In the pseudocode, the expression 'table.[idx].k.load()' appears to contain a stray dot; it should likely read 'table[idx].k.load()'.
  2. [§4.5] The sentence 'the fully concurrent workload is does display significant performance degradation' contains a verb duplication; also, the final sentence 'Resizing performance and should be an important dimension' is grammatically incomplete.
  3. [§3.1] The term 'zero-allocation' is used to describe calloc-style zero-initialized memory that enables copy-on-write; 'zero-initialized allocation' would be less ambiguous and would avoid implying that no allocation occurs.
  4. [§4] The comparison baseline is an in-house implementation of partitioned aggregation, not a production engine's aggregation path; a note about how this choice affects generalizability would be helpful, since real engines may have additional optimizations or overheads.
  5. [References] Reference [16] is cited without a full title; listing the actual paper title would improve completeness.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: central claims are direct experimental measurements, not derived from fitted inputs or self-citation.

full rationale

The paper's main result—that a purpose-built linear-probing concurrent hash table with a customized get-or-insert function can match or outperform partitioning in morsel-driven aggregation—is supported by direct benchmarks on synthetic workloads (Section 4.1, Figures 7, 11–13). There are no parameters fitted to a subset of data and then renamed as predictions; the Folklore* design is specified by Algorithm 1 and its performance is measured, not derived from an assumed conclusion. No load-bearing claim is justified solely by the authors' prior work; citations such as [20], [23], and [29] supply external baselines and prior hash-table designs, and the authors' own contribution is the customized ticketing/update decomposition and its empirical evaluation. The assumption of perfect cardinality estimation (Section 2.4) limits how far the results generalize, and the forced-resize experiment (Section 4.5) shows up to a 5.2x latency increase for unique keys with atomic updates, but these are empirical caveats and robustness concerns about the strength of the practical claim, not circular reasoning. The paper separates ticketing and update stages, and its theoretical statements (e.g., O(k n) thread-local memory usage) are elementary accounting rather than results that presuppose the conclusion. Accordingly, no circular step can be exhibited with the required specificity, and the honest finding is no significant circularity.

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

No new theoretical entities are introduced. Folklore* is an implementation variant of an existing lock-free linear probing hash table, and the ticket is a known indirection technique from MonetDB; neither is a postulated entity requiring independent evidence. The free parameters are the disclosed workload settings, not fitted values.

free parameters (5)
  • Low cardinality = 1000 unique keys
    Workload parameter chosen in Section 2.4; defines the lookup-dominated ticketing case (100% lookup, 0% insertion).
  • High cardinality = 10 million unique keys
    Workload parameter chosen in Section 2.4; defines 90% lookup/10% insertion case.
  • Unique cardinality = 100 million unique keys
    Workload parameter chosen in Section 2.4; defines pure-insert case (0% lookup/100% insertion).
  • Zipf exponent = 0.8
    Skew parameter for the Zipfian workload in Section 2.4, chosen by hand; results depend on this skew level.
  • Heavy-hitter fraction = 50%
    Heavy-hitter workload in Section 2.4 where 50% of rows share the same key; this is the case where partitioning wins at high thread counts.
assumptions (6)
  • domain assumption Morsel-driven execution with columnar vectors and work-stealing is the assumed model.
    Section 2.1; conclusions are scoped to this model and may not transfer to operator-level or pipeline-parallel engines.
  • domain assumption SUM is representative of aggregation functions.
    All experiments use SUM (Section 2.4); the authors generalize to other aggregates without testing them.
  • domain assumption The in-house Rust partitioned baseline accurately represents production algorithms.
    Section 2.2 says the baseline is the algorithm used by DuckDB and Datafusion, but it is not validated against those systems.
  • domain assumption Perfect cardinality estimation is available for sizing.
    Section 2.4 states all experiments except Section 4.5 assume perfect estimation; Section 4.5 tests the cost of violating this.
  • domain assumption All data structures fit in memory.
    Section 4.6 states this; no spill-to-disk path exists for fully concurrent aggregation.
  • standard math Hardware provides correct compare-and-swap and atomic operations.
    Algorithm 1 relies on CAS and acquire/release ordering; no formal correctness proof is given.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Global Hash Tables Strike Back! An Analysis of Parallel GROUP BY Aggregation." pith.science (2026). https://pith.science/paper/RUMZ6BTD

@misc{pith2026250504153,
  author       = {Pith},
  title        = {Pith review of: Global Hash Tables Strike Back! An Analysis of Parallel GROUP BY Aggregation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RUMZ6BTD}},
  note         = {Machine review of arXiv:2505.04153}
}
read the original abstract

Efficiently computing group aggregations (i.e., GROUP BY) on modern architectures is critical for analytic database systems. Hash-based approaches in today's engines predominantly use a partitioned approach, in which incoming data is partitioned by key values so that every row for a particular key is sent to the same thread. In this paper, we revisit a simpler strategy: a fully concurrent aggregation technique using a shared hash table. While approaches using general-purpose concurrent hash tables have generally been found to perform worse than partitioning-based approaches, we argue that the key ingredient is customizing the concurrent hash table for the specific task of group aggregation. Through experiments on synthetic workloads (varying key cardinality, skew, and thread count), we demonstrate that in morsel-driven systems, a purpose-built concurrent hash table can match or surpass partitioning-based techniques. We also analyze the operational characteristics of both techniques, including resizing costs and memory pressure. In the process, we derive practical guidelines for database implementers. Overall, our analysis indicates that fully concurrent group aggregation is a viable alternative to partitioning.

Figures

Figures reproduced from arXiv: 2505.04153 by the authors.

Figure 1
Figure 1. A sample execution of partitioned aggregation. This [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. A sample execution of our fully concurrent aggre [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Performance of the Folklore* hash table with a [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Scaling behavior of various hash maps for ticketing. The top row measures performance as throughput (higher is [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Breakdown of time spent on work by processor [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Scaling behavior of various partial aggregate update methods across different data distributions. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: End-to-end evaluation of scaling behavior of fully concurrent aggregation methods vs. partitioned aggregation. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Percent of time spent on each step of aggregation. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Breakdown of time spent on work by processor [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Instruction count and IPC vs. threads. workload, whose performance is driven by multiple factors, includ￾ing contention, time complexity scaling, etc. We therefore take a layered approach and separate the analysis into three questions: (1) Q1: How much time is spent p…
Figure 11
Figure 11. Figure 11: Scaling behavior of aggregation on ARM (Ampere [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 13
Figure 13. Figure 13: Scaling behavior of fully concurrent aggregation [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 20 canonical work pages

  1. [1]

    Maximilian Bandle, Jana Giceva, and Thomas Neumann. 2021. To Partition, or Not to Partition, That is the Join Question in a Real System. InProceedings of the 2021 International Conference on Management of Data. ACM, Virtual Event China, 168–180. https://doi.org/10.1145/3448016.3452831

    arXiv 2021

  2. [2]

    Bender, Alex Conway, Martín Farach-Colton, William Kuszmaul, and Guido Tagliavini

    Michael A. Bender, Alex Conway, Martín Farach-Colton, William Kuszmaul, and Guido Tagliavini. 2023. Iceberg Hashing: Optimizing Many Hash-Table Criteria at Once.J. ACM70, 6 (Dec. 2023), 1–51. https://doi.org/10.1145/3625817

    doi:10.1145/3625817 2023

  3. [3]

    Altan Birler, Tobias Schmidt, Philipp Fent, and Thomas Neumann. 2024. Simple, Efficient, and Robust Hash Tables for Join Processing. InProceedings of the 20th International Workshop on Data Management on New Hardware. ACM, Santiago AA Chile, 1–9. https://doi.org/10.1145/3662010.3663442

    arXiv 2024

  4. [4]

    Boncz, Marcin Zukowski, and Niels Nes

    Peter A. Boncz, Marcin Zukowski, and Niels Nes. 2005. MonetDB/X100: Hyper- Pipelining Query Execution. www.cidrdb.org, Asilomar, CA, USAW, 225–237. http://cidrdb.org/cidr2005/papers/P19.pdf

    work page 2005

  5. [5]

    John Cieslewicz and Kenneth A. Ross. 2007. Adaptive aggregation on chip multiprocessors. InProceedings of the 33rd International Conference on Very Large Data Bases (VLDB ’07). VLDB Endowment, Vienna, Austria, 339–350

    work page 2007

  6. [6]

    Rob Clucas. [n.d.]. Leapfrog. https://github.com/robclu/leapfrog

    work page

  7. [7]

    Damian Dechev, Peter Pirkelbauer, and Bjarne Stroustrup. 2010. Understanding and Effectively Preventing the ABA Problem in Descriptor-Based Lock-Free Designs. In2010 13th IEEE International Symposium on Object/Component/Service- Oriented Real-Time Distributed Computing. IEEE, Carmona, Spain, 185–192. https: //doi.org/10.1109/isorc.2010.10

    work page doi:10.1109/isorc.2010.10 2010

  8. [8]

    Thanh Do, Goetz Graefe, and Jeffrey Naughton. 2022. Efficient Sorting, Duplicate Removal, Grouping, and Aggregation.ACM Transactions on Database Systems 47, 4 (Dec. 2022), 1–35. https://doi.org/10.1145/3568027

    work page doi:10.1145/3568027 2022

Show all 38 references
  1. [9]

    Dominik Durner, Viktor Leis, and Thomas Neumann. 2019. On the Impact of Memory Allocation on High-Performance Query Processing. InProceedings of the 15th International Workshop on Data Management on New Hardware. ACM, Amsterdam Netherlands, 1–3. https://doi.org/10.1145/3329785.3329918

    2019

  2. [10]

    Philipp Fent and Thomas Neumann. 2021. A practical approach to groupjoin and nested aggregates.Proceedings of the VLDB Endowment14, 11 (July 2021), 2383–2396. https://doi.org/10.14778/3476249.3476288 Publisher: Association for Computing Machinery (ACM)

    2021

  3. [11]

    Gaffney and Jignesh M

    Kevin P. Gaffney and Jignesh M. Patel. 2024. Is Perfect Hashing Practical for OLAP Systems? www.cidrdb.org, Chaminade, HI, USA. https://www.cidrdb.org/ cidr2024/papers/p65-gaffney.pdf

    2024

  4. [12]

    Graefe, A

    G. Graefe, A. Linville, and L.D. Shapiro. 1994. Sort vs. hash revisited.IEEE Transactions on Knowledge and Data Engineering6, 6 (Dec. 1994), 934–944. https: //doi.org/10.1109/69.334883

    1994 doi

  5. [13]

    Graefe and W.J

    G. Graefe and W.J. McKenna. 1993. The Volcano optimizer generator: extensibility and efficient search. InProceedings of IEEE 9th International Conference on Data Engineering. IEEE Comput. Soc. Press, Vienna, Austria, 209–218. https://doi.org/ 10.1109/icde.1993.344061

    1993

  6. [14]

    Pearlmutter, and Phil Maguire

    Robert Kelly, Barak A. Pearlmutter, and Phil Maguire. 2020. Lock-Free Hopscotch Hashing. InSymposium on Algorithmic Principles of Computer Systems. Society for Industrial and Applied Mathematics, Philadelphia, PA, 45–59. https://doi. org/10.1137/1.9781611976021.4

    2020 doi

  7. [15]

    Timo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, and Peter Boncz. 2018. Everything you always wanted to know about compiled and vectorized queries but were afraid to ask.Proceedings of the VLDB Endowment11, 13 (Sept. 2018), 2209–2222. https://doi.org/10....

    2018

  8. [16]

    Andreas Kipf, Michael Freitag, Dimitri Vorona, Peter Boncz, Thomas Neumann, and Alfons Kemper. 2019. Estimating filtered group-by queries is hard: Deep learning to the rescue. Los Angeles, CA, USA

    2019

  9. [17]

    Laurens Kuiper, Peter Boncz, and Hannes Mühleisen. 2024. Robust External Hash Aggregation in the Solid State Age. In2024 IEEE 40th International Conference on Data Engineering (ICDE). IEEE, Utrecht, Netherlands, 3753–3766. https: //doi.org/10.1109/icde60146.2024.00288

    2024

  10. [18]

    Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan, Nga Tran, Ben Vandiver, Lyric Doshi, and Chuck Bear. 2012. The vertica analytic database: C-store 7 years later.Proceedings of the VLDB Endowment5, 12 (Aug. 2012), 1790–1801. https://doi.org/10.14778/2367502.2367518

    2012

  11. [19]

    Andrew Lamb, Daniël Heres, and Raphael Taylor-Davies. 2023. Aggregating Millions of Groups Fast in Apache Arrow DataFusion 28.0.0. https://arrow. apache.org/blog/2023/08/05/datafusion_fast_grouping/

    2023

  12. [20]

    Viktor Leis, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2014. Morsel- driven parallelism: a NUMA-aware query evaluation framework for the many- core age. InProceedings of the 2014 ACM SIGMOD International Conference on Management of Data. ACM, Snowbird Utah USA, 743–754. ...

    2014

  13. [21]

    Andersen, Michael Kaminsky, and Michael J

    Xiaozhou Li, David G. Andersen, Michael Kaminsky, and Michael J. Freedman

  14. [22]

    Hua Luan and Lei Chang. 2022. An experimental study of group-by and aggre- gation on CPU-GPU processors.Journal of Engineering and Applied Science69, 1 (Dec. 2022). https://doi.org/10.1186/s44147-022-00108-1 Publisher: Springer Science and Business Media LLC

    2022 doi

  15. [23]

    Tobias Maier, Peter Sanders, and Roman Dementiev. 2018. Concurrent Hash Tables: Fast and General(?)!ACM Transactions on Parallel Computing5, 4 (Dec. 2018), 1–32. https://doi.org/10.1145/3309206 Publisher: Association for Com- puting Machinery (ACM)

    2018 doi

  16. [24]

    Ingo Müller, Peter Sanders, Arnaud Lacurie, Wolfgang Lehner, and Franz Färber

  17. [25]

    Raghunath Othayoth Nambiar and Meikel Poess. 2006. The making of TPC-DS. InProceedings of the 32nd International Conference on Very Large Data Bases (VLDB ’06). VLDB Endowment, Seoul, Korea, 1049–1058

    2006

  18. [26]

    Bender, Alex Conway, Martin Farach-Colton, William Kuszmaul, Guido Tagliavini, and Rob Johnson

    Prashant Pandey, Michael A. Bender, Alex Conway, Martin Farach-Colton, William Kuszmaul, Guido Tagliavini, and Rob Johnson. 2023. IcebergHT: High Performance Hash Tables Through Stability and Low Associativity.Proc. ACM Manag. Data1, 1 (May 2023), 1–26. https://doi.org/10.1145...

    2023 doi

  19. [27]

    Jeff Preshing. 2016. Leapfrog Probing. https://preshing.com/20160314/leapfrog- probing

    2016

  20. [28]

    Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. InProceedings of the 2019 International Conference on Management of Data. ACM, Amsterdam Netherlands, 1981–1984. https://doi.org/10.1145/ 3299869.3320212

    2019

  21. [29]

    Lohman, Tim Malkemus, Rene Mueller, Ippokratis Pandis, Berni Schiefer, David Sharpe, Richard Sidle, Adam Storm, and Liping Zhang

    Vijayshankar Raman, Gopi Attaluri, Ronald Barber, Naresh Chainani, David Kalmuk, Vincent KulandaiSamy, Jens Leenstra, Sam Lightstone, Shaorong Liu, Guy M. Lohman, Tim Malkemus, Rene Mueller, Ippokratis Pandis, Berni Schiefer, David Sharpe, Richard Sidle, Adam Storm, and Liping...

    2013 doi

  22. [30]

    Bashar Romanous, Skyler Windh, Ildar Absalyamov, Prerna Budhkar, Robert Halstead, Walid Najjar, and Vassilis Tsotras. 2021. Efficient local locking for massively multithreaded in-memory hash-based operators.The VLDB Journal30, 3 (May 2021), 333–359. https://doi.org/10.1007/s00...

    2021 doi

  23. [31]

    Gaurav Vaghasiya and Shiva Jahangiri. 2024. [Experiments & Analysis] Hash- Based vs. Sort-Based Group-By-Aggregate: A Focused Empirical Study [Extended Version]. https://doi.org/10.48550/arXiv.2411.13245 arXiv:2411.13245 [cs]

    2024 doi arXiv

  24. [32]

    Gaurav Vaghasiya and Shiva Jahangiri. 2024. A Hybrid Approach to Group-By and Aggregation Query Execution. In2024 IEEE International Conference on Big Data (BigData). IEEE, Washington, DC, USA, 3799–3808. https://doi.org/10. 1109/BigData62323.2024.10825803

    2024

  25. [33]

    Joel Wejdenstål. [n.d.]. DashMap. https://github.com/xacrimon/dashmap

  26. [34]

    Ahmad Yasin. 2014. A Top-Down method for performance analysis and counters architecture. In2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, CA, USA, 35–44. https://doi.org/10.1109/ ISPASS.2014.6844459

    2014

  27. [35]

    Ross, and Norases Vesdapunt

    Yang Ye, Kenneth A. Ross, and Norases Vesdapunt. 2011. Scalable Aggregation on Multicore Processors. InProceedings of the Seventh International Workshop on Data Management on New Hardware. ACM, Athens Greece, 1–9. https: //doi.org/10.1145/1995441.1995442

    2011

  28. [36]

    Franklin, Scott Shenker, and Ion Stoica

    Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker, and Ion Stoica. 2010. Spark: cluster computing with working sets. InProceedings of the 2nd USENIX Conference on Hot Topics in Cloud Computing (HotCloud’10). USENIX Association, Boston, MA, 10. https://doi.o...

    2010

  29. [2014]

    InProceed- ings of the Ninth European Conference on Computer Systems

    Algorithmic improvements for fast concurrent Cuckoo hashing. InProceed- ings of the Ninth European Conference on Computer Systems. ACM, Amsterdam The Netherlands, 1–14. https://doi.org/10.1145/2592798.2592820

  30. [2015]

    InProceedings of the 2015 ACM SIGMOD International Conference on Management of Data

    Cache-Efficient Aggregation: Hashing Is Sorting. InProceedings of the 2015 ACM SIGMOD International Conference on Management of Data. ACM, Melbourne Victoria Australia, 1123–1136. https://doi.org/10.1145/2723372.2747644

    2015

Pith tools

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