Pith. sign in

REVIEW 3 major objections 4 minor 26 references

[Experiments \& Analysis] Hash-Based vs. Sort-Based Group-By-Aggregate: A Focused Empirical Study [Extended Version]

T0 review · 3 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Hash group-by wins on small data, sort on large data

desk verdict Honest, well-run AsterixDB experiments; the crossover is real for this system but not new, and the open-type normalization issue muddies the small-group story. read the letter →

arxiv 2411.13245 v2 pith:L7N5YNZP submitted 2024-11-20 cs.DB

Gaurav Vaghasiya , Shiva Jahangiri This is my paper · ORCID
classification cs.DB
keywords group-by-aggregatehash-basedaggregationsort-basedspillinggroupcardinalityAsterixDBempiricalstudyqueryoptimization
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 reports a controlled, head-to-head comparison of hash-based versus sort-based group-by-aggregate execution on Apache AsterixDB, varying dataset size, group count, data type, and string characteristics. The central claim is that the two methods have opposite sweet spots: hash-based aggregation is preferable when datasets are small or group counts are low (because it stays in memory and avoids sorting), while sort-based aggregation wins for large datasets, high group cardinality, and memory-limited situations (because it handles spilling more predictably). The authors argue their controlled Wisconsin-style experiments isolate the GBA operator better than TPC-H and TPC-DS, whose additional operators mask its behavior. If the claim holds, query optimizers should pick a group-by algorithm based on estimated group cardinality and memory pressure, not just on dataset size.

What carries the argument

The load-bearing mechanism is the interaction between a fixed per-partition operator memory budget (64 MB per data partition) and the number of distinct group keys. In AsterixDB, sort-based GBA uses an external merge sort with normalized keys and a record pointer array for comparison-based ordering, then aggregates in a merge pass; hash-based GBA uses a partition table plus a hash table, spilling partitions to disk recursively when the aggregate state exceeds the budget. When group cardinality is low, the hash table fits in memory and avoids all sorting; when cardinality is high, hash-table overhead (roughly a third of the memory) forces earlier and heavier spilling, while the sort-based method spills in a more controlled merge order. This spilling-versus-comparison trade-off is what the paper measures in its execution-time, spilling, and sort-comparison plots.

What would settle it

Run the same Wisconsin-style group-by experiments on another parallel DBMS with an equivalent per-operator memory budget and the same open-record layout; if the crossover point (where sort starts beating hash) moves by more than a small factor or disappears, the general trend claimed here is AsterixDB-specific rather than intrinsic to the algorithm families. Alternatively, vary the per-partition budget from 64 MB to 1 GB and observe whether hash-based remains competitive at high group counts once memory pressure is relieved.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes a performance crossover: with a fixed per-partition memory budget of 64 MB, hash-based group-by is faster than sort-based when the input fits in memory or produces few groups (e.g., ten groups), because it performs no sorting and spills almost nothing. As group cardinality rises toward one million, the hash table overflows the memory budget, its spilling rises sharply, and its execution time climbs steeply, while sort-based group-by degrades more gradually and ends up faster. The same mechanism explains the string findings: hash-based suffers from the extra memory taken by hash-table overhead when keys are unique, while sort-based slows dramatically when keys share long common prefixes, because character-by-character comparisons multiply. The paper also reports that aggregate type (COUNT vs. SUM) does not change the ranking, and that on the complex TPC workloads the two methods are often comparable because the GBA operator receives relatively little data after filtering and joins.

Load-bearing premise

The experiments assume the AsterixDB sort and hash group-by implementations are representative of the general algorithm families, and that the fixed 64 MB per-partition memory budget, the open data type, and the hash-partition exchange plan do not secretly determine the crossover.

Editorial extensions

If this is right

  • Query optimizers that estimate group cardinality can choose hash-based GBA for low-cardinality groupings and sort-based GBA for high-cardinality or memory-limited ones, avoiding spills.
  • When a downstream operator needs sorted output, sort-based GBA can serve double duty, which the paper identifies as a reason it stays competitive on TPC-H queries 9 and 13.
  • The performance gap between the two methods widens with open-typed, long, or prefix-similar string keys, making data type a first-class input to operator choice.
  • The near-identical results for COUNT and SUM suggest aggregate function type matters less for choosing between the two approaches than group cardinality and memory pressure.
  • Databases that expose memory-budget hints can use these results to set or advise operator memory so that hash aggregation avoids spill regimes.

Reading between the lines

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

  • The same crossover logic should apply on other shared-nothing systems, but the memory-budget threshold is likely system-specific; the qualitative result (hash prefers low cardinality, sort prefers high cardinality and tight memory) is the transferable part.
  • An adaptive operator could start with hashing and switch to sorting when its spill rate crosses a threshold, effectively tracking the crossover at runtime without query-plan statistics.
  • The paper's open-data-type setup is a conservative case for sorting (it disables normalized-key comparison); on closed datasets with fixed-width fields, sort-based GBA may close part of the low-cardinality gap.
  • The observed sharp degradation of hash-based GBA at one million groups suggests a practical ceiling heuristic: if estimated groups exceed a memory-derived bound, route the query to sort.
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

3 major / 4 minor

Summary. This paper reports a focused empirical comparison of sort-based and hash-based group-by-aggregate (GBA) execution in Apache AsterixDB. It uses TPC-H and TPC-DS workloads plus controlled synthetic data from a modified Wisconsin benchmark to measure execution time, disk spilling, and sort-comparison counts across data size, group cardinality, aggregation type, and data type. The central claim is a crossover: hash-based GBA is preferable for small datasets or low group counts, while sort-based GBA performs better under high group cardinality or memory pressure. The paper is explicitly an AsterixDB study, but Section 2.2 asserts that the findings are extendable to other similar systems.

Significance. If taken as a statement about AsterixDB's two GBA implementations under the tested configuration, this is a useful and mostly well-documented empirical datapoint: it reports spill-volume and comparison-count evidence for the proposed mechanism, uses both realistic TPC queries and controlled synthetic data, discards the first of 11 runs, and describes the cluster and memory budget concretely. The use of an author-created data generator is not itself circular because the generator does not encode the outcome being measured. However, the paper's abstract and conclusion generalize well beyond what the experiments establish. The main confound—the sort-based operator runs without normalized-key sorting on open-type records—is a load-bearing threat to the central crossover claim, and the single-system, single-plan design does not support the stated generality. The study is therefore a solid AsterixDB-specific experiment but needs either an additional closed-type control or substantially narrowed claims before it can support the broad guidance in the abstract.

major comments (3)
  1. [Section 3.1, Sections 4.3-4.5] The central crossover result is measured under an implementation choice that asymmetrically disadvantages the sort-based operator. Section 3.1 states that "when using open types, the actual records are sorted rather than the normalized representation," and Section 4.3 states that Expr. 2's Wisconsin datasets use AsterixDB's open data type; Expr. 4 "remains consistent with earlier experiments" and appears to inherit the same setting. Section 4.4.2 explicitly classifies its dataset as Open to disable normalized keys. With open types, the sort-based GBA performs byte-wise, full-record comparisons while the hash-based GBA keeps only an aggregate entry per group. Consequently, in the low-cardinality experiments (10 groups), the hash operator's memory footprint collapses to about ten entries per partition while the sort operator's working set remains the full record stream, so the observed hash advantage is at least partly an artifact of this representation asymmetry rather than a general property of hash versus sort grouping. The paper must either rerun the controlled experiments with a closed data type so that normalized-key sorting is enabled, or explicitly restrict the conclusions to open-type, AsterixDB-specific execution. As written, the abstract's general guidance is not supported.
  2. [Abstract and Section 6] The executive summary overstates and internally mismatches the experimental results. The abstract says "sort-based methods excel in scenarios with large datasets," but Expr. 2 (Figure 6) shows the opposite for every tested dataset size from 2 GB to 64 GB when the group count is 10; the actual crossover in Section 4.5 is about group cardinality, not dataset size per se. The paper's own conclusion correctly conditions on "high-cardinality or memory-limited scenarios," which is a different statement from the abstract's "large datasets" clause. Additionally, memory pressure is not treated as an independent variable: Section 4.1 fixes the GBA memory budget at 64 MB per data partition for all experiments, so the paper demonstrates only that sort outperforms hash under one memory setting, not that the ranking is caused by memory pressure. The abstract and Section 6 should be rewritten to state the conditional result actually shown: for AsterixDB with open-type records and a fixed 64 MB per-partition budget, hash wins at low group cardinality and sort wins at high group cardinality.
  3. [Section 2.2] The claim in Section 2.2 that the findings are "extendable to other systems" is not tested and is too strong for the evidence. All experiments use one execution plan (local aggregation, hash-partition exchange, global aggregation, as shown in Figure 3), one operator memory budget, one record representation (open ADM), and one DBMS implementation of each algorithm family. A second system, a second plan, or even a sensitivity analysis over memory budgets and data types would be needed to justify cross-system generalization. I am not requiring a full multi-system study, but the scope of the claim should match the evidence: without such additional evidence, the conclusions should be framed as "in AsterixDB under these settings," not as general guidance for hash- versus sort-based GBA.
minor comments (4)
  1. [Section 4.1] The paper does not state the AsterixDB version used; a version number would improve reproducibility.
  2. [Section 4.3 and Figure 7] It should be defined explicitly what "amount of data spilled" counts: raw sort-run spilling, aggregated-output spilling, or both. The claim that sort-based GBA spills little with 10 groups is surprising if full records are sorted, and a precise definition would clarify the mechanism.
  3. [Section 4.3 and Figure 6] The paper reports only the average of the last 10 runs, with no variance information or per-trial data. A standard deviation or raw timing table would help assess the reliability of the smaller differences, especially in the TPC experiments of Figure 5.
  4. [Section 4.4.2] There is a typo in the text: "respectively, in Figures1111-(a), -(b), and -(c)" should be "Figure 11-(a), -(b), and -(c)."

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports direct empirical measurements and does not derive its conclusions from fitted parameters or self-citation chains.

full rationale

This is an empirical study, not a derivation, so most circularity patterns do not apply. The central claims about when hash-based versus sort-based group-by-aggregate is faster are summaries of directly measured execution times, spilling, and comparison counts on Apache AsterixDB. No parameter is fitted to a subset of the data and then renamed as a prediction; no uniqueness theorem is imported from the authors' prior work; and no ansatz is smuggled in via citation. The main author-related artifact is the Wisconsin benchmark JSON data generator [4,19], used to create controlled datasets. That generator controls input characteristics such as group counts and string distributions, but it does not encode or determine the measured performance outcomes, so the self-citation is not load-bearing in a circular sense. The TPC-H and TPC-DS workloads are external benchmarks. The open-data-type condition that disables normalized-key sorting in AsterixDB is a plausible threat to the generalizability of the conclusions, but it is a validity concern, not circularity: the experiments still measure actual system behavior under stated conditions, and the conclusions do not reduce by definition to those conditions. The paper even acknowledges the difficulty of isolating the GBA operator in the TPC benchmarks and the engineered nature of some string-prefix experiments, which further supports treating the findings as conditional empirical observations rather than as results forced by the experimental setup. Overall, the derivation chain is self-contained with respect to circularity, and no specific reduction of a conclusion to an input by construction can be exhibited.

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

The paper's claims rest on experimental setup choices rather than mathematical axioms. The main 'axioms' are that AsterixDB implementations represent the general algorithm families, the plan and memory budget are not biased, and the averaging protocol is representative. There are no fitted model parameters in the sense of a derivation; the listed values are hand-chosen experimental settings that influence the crossover.

free parameters (3)
  • Per-partition GBA memory budget = 64 MB
    Set in Section 4.1. Spilling behavior, the main performance differentiator, depends directly on this budget; a larger budget would likely shift the crossover toward hash-based.
  • Node memory limit = ~16 GB per node
    Set in Section 4.1 by external memory-blocking programs. This constrains cache effects and forces spill scenarios; results may differ with more memory.
  • Synthetic data distribution parameters = String lengths 10-200, 20%/80% split; common prefixes of 0 and 100 chars
    Chosen in Section 4.4 to expose worst cases for string comparison. The conclusions about string handling are tied to these hand-picked distributions.
assumptions (3)
  • domain assumption AsterixDB's sort and hash GBA operators are representative of the two algorithm families across DBMSs.
    Stated in Section 2.2: 'our findings... extendable to other systems.' No cross-system experiment is run, so this is an assumption.
  • domain assumption The query plan (local aggregation, hash-partition exchange, global aggregation) does not confound operator comparison.
    Described in Section 3.1. Both operators run inside the same plan, but exchange and plan-level costs are not separately measured.
  • domain assumption Discarding the first run and averaging runs 2-11 captures steady-state performance.
    Described in Section 4.1. The paper assumes cold-cache effects are only in the first run; no variance or warm-up statistics are shown.

how reviews work

0 comments
Cite this review

Pith. "Pith review of [Experiments \& Analysis] Hash-Based vs. Sort-Based Group-By-Aggregate: A Focused Empirical Study [Extended Version]." pith.science (2026). https://pith.science/paper/L7N5YNZP

@misc{pith2026241113245,
  author       = {Pith},
  title        = {Pith review of: [Experiments \& Analysis] Hash-Based vs. Sort-Based Group-By-Aggregate: A Focused Empirical Study [Extended Version]},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L7N5YNZP}},
  note         = {Machine review of arXiv:2411.13245}
}
read the original abstract

Group-by-aggregate (GBA) queries are integral to data analysis, allowing users to group data by specific attributes and apply aggregate functions such as sum, average, and count. Database Management Systems (DBMSs) typically execute GBA queries using either sort- or hash-based methods, each with unique advantages and trade-offs. Sort-based approaches are efficient for large datasets but become computationally expensive due to record comparisons, especially in cases with a small number of groups. In contrast, hash-based approaches offer faster performance in general but require significant memory and can suffer from hash collisions when handling large numbers of groups or uneven data distributions. This paper presents a focused empirical study comparing these two approaches, analyzing their strengths and weaknesses across varying data sizes, datasets, and group counts using Apache AsterixDB. Our findings indicate that sort-based methods excel in scenarios with large datasets or when subsequent operations benefit from sorted data, whereas hash-based methods are advantageous for smaller datasets or scenarios with fewer groupings. Our results provide insights into the scenarios where each method excels, offering practical guidance for optimizing GBA query performance.

Figures

Figures reproduced from arXiv: 2411.13245 by the authors.

Figure 1
Figure 1. AsterixDB’s Architecture AsterixDB’s entry point for user requests is its Cluster Controller (CC) node, which compiles and transforms the requests into exe￾cutable jobs. Its Node Controllers (NCs) are the worker nodes that execute the jobs sent by the CC. One NC also serves as the Meta Data Controller Node and provides access to AsterixDB’s metadata. Each NC manages one or more data partitions (DPs) as shown in [PI… view at source ↗
Figure 3
Figure 3. Execution plan for GBA in AsterixDB fields as hash keys, ensuring identical fields are placed together. The redistributed records are then processed by a second Group-By operator for final parallel aggregation on each NC. We refer to this phase as “global aggregation". The results are then sent to the CC and delivered to the user. 3.2 Hash-based GBA In AsterixDB, hash-based Group-By uses a hash function to process e… view at source ↗
Figure 4
Figure 4. Workflow of Hash-Based Group-By for GBA queries [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: Expr. 1 - (a) TPC-H, (b) TPC-DS. *Q18 has 2 Group [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 7
Figure 7. Figure 7: Expr. 2 - Spilling and Sort Comparisons for ‘COUNT’ [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 6
Figure 6. Figure 6: Expr. 2 - Impact of Aggregation Types The data is generated using the Wisconsin Data Generator[4] and loaded into datasets defined with AsterixDB’s open data type, with a UUID as the primary key [7]. The UUID is auto-generated by AsterixDB with random values, ensuring …
Figure 8
Figure 8. Figure 8: Expr. 3 - Impact of Data Types [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Expr. 3 - Spilling and Sort Comparisons for ‘Random [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]
Figure 10
Figure 10. Figure 10: Expr. 3 - Spilling and Sort Comparisons for ‘Unique [PITH_FULL_IMAGE:figures/full_fig_p006_10.png]
Figure 11
Figure 11. Figure 11: Expr. 3-Impact of Variable Length Strings [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]
Figure 13
Figure 13. Figure 13: Expr. 4 - Impact of number of groups We anticipated that the sort-based approach would face chal￾lenges with sorting and spilling as the number of groups increased, while the hash-based approach was expected to encounter memory limitations, resulting in higher disk I/…
Figure 12
Figure 12. Figure 12: Expr. 3-Impact of various types of Strings [PITH_FULL_IMAGE:figures/full_fig_p007_12.png]
Figure 14
Figure 14. Figure 14: Expr. 4 - Spillings and Sort Comparisons for Vari [PITH_FULL_IMAGE:figures/full_fig_p008_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages

  1. [1]

    https://asterixdb.apache.org/

    Apache AsterixDB. https://asterixdb.apache.org/. 2021

    work page 2021

  2. [2]

    https://www.tpc.org/tpcds/

    TPC-DS Benchmark. https://www.tpc.org/tpcds/. 2021

    work page 2021

  3. [3]

    https://www.tpc.org/tpch/

    TPC-H Benchmark. https://www.tpc.org/tpch/. 2021

    work page 2021

  4. [4]

    https://github.com/shivajah/JSON- Wisconsin-Data-Generator

    Wisconsin Benchmark Data Generator. https://github.com/shivajah/JSON- Wisconsin-Data-Generator. 2021

    work page 2021

  5. [5]

    Borkar, Yingyi Bu, Michael J

    Sattam Alsubaiee, Yasser Altowim, Hotham Altwaijry, Alexander Behm, Vinayak R. Borkar, Yingyi Bu, Michael J. Carey, Inci Cetindil, Madhusudan Chee- langi, Khurram Faraaz, Eugenia Gabrielova, Raman Grover, Zachary Heilbron, Young-Seok Kim, Chen Li, Guangqiang Li, Ji Mahn Ok, Nicola Onose, Pouria Pirzadeh, Vassilis J. Tsotras, Rares Vernica, Jian Wen, and T...

    work page 1905

  6. [6]

    Borkar, Zachary Heilbron, Young- Seok Kim, Michael J

    Sattam Alsubaiee, Alexander Behm, Vinayak R. Borkar, Zachary Heilbron, Young- Seok Kim, Michael J. Carey, Markus Dreseler, and Chen Li. Storage management in asterixdb. Proc. VLDB Endow., 7(10):841–852, 2014

    work page 2014

  7. [7]

    AsterixDB SQL++ User Manual , 2023

    Apache AsterixDB. AsterixDB SQL++ User Manual , 2023

    work page 2023

  8. [8]

    Astrahan, Mike W

    Morton M. Astrahan, Mike W. Blasgen, Donald D. Chamberlin, Kapali P. Eswaran, Jim Gray, Patricia P. Griffiths, W. Frank King III, Raymond A. Lorie, Paul R. McJones, James W. Mehl, Gianfranco R. Putzolu, Irving L. Traiger, Bradford W. Wade, and Vera Watson. System R: relational approach to database management. ACM Trans. Database Syst., 1(2):97–137, 1976

    work page 1976

Show all 26 references
  1. [9]

    Tamer Özsu

    Cagri Balkesen, Gustavo Alonso, Jens Teubner, and M. Tamer Özsu. Multi-core, main-memory joins: Sort vs. hash revisited. Proc. VLDB Endow., 7(1):85–96, 2013

    2013

  2. [10]

    Dina Bitton and David J. DeWitt. Duplicate record elimination in large data files. ACM Trans. Database Syst., 8(2):255–265, 1983

    1983

  3. [11]

    Naughton

    Thanh Do, Goetz Graefe, and Jeffrey F. Naughton. Efficient sorting, duplicate removal, grouping, and aggregation. ACM Trans. Database Syst., 47(4):16:1–16:35, 2022

    2022

  4. [12]

    Query evaluation techniques for large databases

    Goetz Graefe. Query evaluation techniques for large databases. ACM Comput. Surv., 25(2):73–170, 1993

    1993

  5. [13]

    Goetz Graefe. Sort-merge-join: An idea whose time has(h) passed? In Proceedings of the Tenth International Conference on Data Engineering, February 14-18, 1994, Houston, Texas, USA, pages 406–417. IEEE Computer Society, 1994

    1994

  6. [14]

    Implementing sorting in database systems

    Goetz Graefe. Implementing sorting in database systems. ACM Comput. Surv., 38(3):10, 2006

    2006

  7. [15]

    New algorithms for join and grouping operations

    Goetz Graefe. New algorithms for join and grouping operations. Comput. Sci. Res. Dev., 27(1):3–27, 2012

    2012

  8. [16]

    Goetz Graefe, Ann Linville, and Leonard D. Shapiro. Sort versus hash revisited. IEEE Trans. Knowl. Data Eng. , 6(6):934–944, 1994

    1994

  9. [17]

    Haas, Michael J

    Laura M. Haas, Michael J. Carey, Miron Livny, and Amit Shukla. Seeking the truth about ad hoc join costs. VLDB J., 6(3):241–256, 1997

    1997

  10. [18]

    A scan-driven sort facility for a relational database system

    Theo Härder. A scan-driven sort facility for a relational database system. In Proceedings of the Third International Conference on Very Large Data Bases, October 6-8, 1977, Tokyo, Japan, pages 236–244. IEEE Computer Society, 1977

    1977

  11. [19]

    Wisconsin benchmark data generator: To JSON and beyond

    Shiva Jahangiri. Wisconsin benchmark data generator: To JSON and beyond. In Guoliang Li, Zhanhuai Li, Stratos Idreos, and Divesh Srivastava, editors,SIGMOD ’21: International Conference on Management of Data, Virtual Event, China, June 20-25, 2021, pages 2887–2889. ACM, 2021

    2021

  12. [20]

    Enhancing Apache AsterixDB for Efficient Big Data Search and Analytics

    Taewoo Kim. Enhancing Apache AsterixDB for Efficient Big Data Search and Analytics. PhD thesis, University of California, Irvine, USA, 2018

    2018

  13. [21]

    Borkar, Yingyi Bu, Michael J

    Taewoo Kim, Alexander Behm, Michael Blow, Vinayak R. Borkar, Yingyi Bu, Michael J. Carey, Murtadha Al Hubail, Shiva Jahangiri, Jianfeng Jia, Chen Li, Chen Luo, Ian Maxon, and Pouria Pirzadeh. Robust and efficient memory management in apache asterixdb. Softw. Pract. Exp., 50(7)...

    2020

  14. [22]

    The effect of bucket size tuning in the dynamic hybrid GRACE hash join method

    Masaru Kitsuregawa, Masaya Nakayama, and Mikio Takagi. The effect of bucket size tuning in the dynamic hybrid GRACE hash join method. In Peter M. G. Apers and Gio Wiederhold, editors, Proceedings of the Fifteenth International Conference on Very Large Data Bases, August 22-25,...

    1989

  15. [23]

    Cache-efficient aggregation: Hashing is sorting

    Ingo Müller, Peter Sanders, Arnaud Lacurie, Wolfgang Lehner, and Franz Färber. Cache-efficient aggregation: Hashing is sorting. In Timos K. Sellis, Susan B. Davidson, and Zachary G. Ives, editors, Proceedings of the 2015 ACM SIGMOD International Conference on Management of Dat...

    2015

  16. [24]

    Hash-partitioned join method using dynamic destaging strategy

    Masaya Nakayama, Masaru Kitsuregawa, and Mikio Takagi. Hash-partitioned join method using dynamic destaging strategy. In François Bancilhon and David J. DeWitt, editors, Fourteenth International Conference on Very Large Data Bases, August 29 - September 1, 1988, Los Angeles, C...

    1988

  17. [25]

    Carey, and Till Westmann

    Pouria Pirzadeh, Michael J. Carey, and Till Westmann. Bigfun: A performance study of big data management system functionality. In 2015 IEEE International Conference on Big Data (IEEE BigData 2015), Santa Clara, CA, USA, October 29 - November 1, 2015, pages 507–514. IEEE Comput...

    2015

  18. [26]

    Leonard D. Shapiro. Join processing in database systems with large main memo- ries. ACM Trans. Database Syst., 11(3):239–264, 1986

    1986

Pith tools

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