Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

Redbench: A Benchmark Reflecting Real Workloads

T0 review · 4 major / 5 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 Redbench recreates real production query patterns in 30 benchmark workloads by resampling standard benchmark queries to match Redshift fleet statistics.

desk verdict Redbench is a genuine, well-scoped attempt to build a repetition-aware benchmark from real production metadata; the construction is precise but the realism claim outruns the evidence. read the letter →

arxiv 2506.12488 v1 pith:E3NOKSIL submitted 2025-06-14 cs.DB

Skander Krid , Mihail Stoian , Andreas Kipf This is my paper · ORCID
classification cs.DB
keywords RedbenchRedsetbenchmarkingqueryrepetitionworkloaddriftscansetinstance-optimizedsystemslearneddatabasecomponents
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 argues that learned and workload-driven database components cannot be validated properly with current benchmarks because those benchmarks do not reproduce how real users issue queries. It introduces Redbench, a collection of 30 workloads built from Redset, a published set of query metadata from 200 Redshift clusters over three months. Each workload is produced by sampling queries from JOB, CEB, or TPC-DS and aligning them to one Redset user's statistics, preserving query repetition rate, workload drift, and relative join complexity. If the alignment works, Redbench would give the learned-systems community a testbed where an optimization that exploits recurring queries or adapts to shifting predicates can be measured under production-like conditions rather than against uniform synthetic workloads.

What carries the argument

The load-bearing mechanism is a greedy workload sampler that turns a Redset user's timestamped query log into a sequence of support-benchmark queries. It uses a query hash—the combination of scanset, join count, table-scan count, and Redset's feature_fingerprint—to detect repeats: a repeated hash maps to the same benchmark query instance, a known scanset maps to the previously chosen template, and a new scanset maps to the unused template with the closest normalized join count. The query repetition rate, the ratio of occurrences whose hash has already appeared, is the quantity the sampler is engineered to reproduce. A fallback strategy fills the remaining gaps when templates or instances run out, and the same relative temporal order is retained by replaying mapped queries back-to-back in original arrival order.

What would settle it

Take the 30 Redbench workloads and, for the same Redset users, compare the empirical distribution of scansets and the distribution of gaps between repeated queries; a significant divergence, especially in the 18% fallback portion, would show that the benchmark reproduces repetition counts but not the table-access and drift patterns that learned components rely on.

Watch

Extended reading notes

Core claim

The paper's central claim is that a benchmark can inherit real workload characteristics by statistical alignment rather than by replaying production queries directly. Redbench defines each Redset query by a hash (scanset, number of joins, number of table scans, feature_fingerprint) and a scanset (the set of persistent tables scanned), then maps a Redset user's query timeline onto the closest query templates and instances of a support benchmark. By construction, the query repetition rate—the fraction of queries whose hash has already appeared—is preserved exactly, and the number of joins is preserved in a normalized, relative sense so the shape of the join-complexity curve over time matches. Table scan sets are replicated only best-effort, bounded by support-benchmark table coverage and template diversity, and about 18% of mapped queries fall back to random reuse of instances. Redbench ships with two instantiations, redbench[imdb] and redbench[tpc-ds], and is intended to be support-benchmark agnostic.

Load-bearing premise

The load-bearing premise is that mapping Redset queries to support-benchmark queries by hash and normalized join count, with random fallback for about 18% of queries, preserves the workload features that learned components actually depend on: query repetition, workload drift, and table-scan repetitiveness.

Editorial extensions

If this is right

  • Learned cardinality estimators and query optimizers can be trained and evaluated on workloads whose query repetition spans the full 0–100% range observed in Redset, which TPC-H, TPC-DS, DSB, and CAB do not provide.
  • Systems that exploit table scan repetitiveness, such as multidimensional data layouts and predicate caching, can be tested against scanset structure that approximates production access patterns, though not exactly.
  • Because Redbench is support-benchmark agnostic, any benchmark or synthetic query generator with enough templates and instances can be substituted, making fidelity improvements a matter of plugging in richer support.
  • Redbench currently discards absolute timestamps, so evaluating resource-allocation and elastic-scaling systems requires the planned CAB integration that preserves wall-clock pacing and peaks.

Reading between the lines

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

  • The fallback that randomly reuses query instances for roughly 18% of queries could introduce artificial correlations between unrelated templates; a careful evaluation should isolate how much of the reproduced repetition rate comes from fallback reuse rather than real re-querying.
  • Because each repetition bucket contains a low-, median-, and high-variability user, the 30 workloads double as a natural transfer-learning experiment: train a learned component on one variability profile and test on another to measure robustness to workload drift.
  • The prefiltering excludes cache-answered queries, self-joins, and join-free queries, so Redbench covers join-heavy, read-only analytical traffic; extending it to updates would address the other half of Redshift's fleet.
  • If scanset-to-scanset equivalence is later achieved with synthetically generated templates, Redbench would stop being a proxy and become a controllable generator of production-like workloads, letting researchers vary repetition and drift independently.
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 / 5 minor

Summary. The paper introduces Redbench, a benchmark consisting of 30 user workloads generated from Redset query metadata by mapping Redset query sequences to queries of support benchmarks (JOB/CEB and TPC-DS). The mapping is designed to preserve query repetition rate, relative join complexity over time, and, in a best-effort manner, scansets. The paper contributes a methodology, a released artifact, and a categorization of what learned and workload-aware components require from a benchmark, and it positions Redbench as a more realistic alternative to TPC-H, TPC-DS, DSB, and CAB for evaluating workload-driven systems.

Significance. If the preservation claims held quantitatively, Redbench would be a valuable step beyond existing benchmarks for the learned-systems community because it would inherit real repetition and drift patterns from Redset while remaining instantiable with well-studied support benchmarks. The construction is precisely specified, the artifacts are publicly released, and the paper identifies a real gap in current evaluation practice. However, the current evidence is insufficient to establish the central 'reflects real workloads' claim: the repetition-rate guarantee is partly definitional and partly affected by fallback behavior, the effect of prefiltering is unquantified, scanset preservation is explicitly best-effort, and the only empirical validation figure covers one of ten repetition buckets.

major comments (4)
  1. [3.2, 3.6] The headline claim in Sec. 3.6 that 'Redbench precisely replicates the query repetition rate observed in Redset' is under-specified because Sec. 3.2 applies several non-neutral filters before the repetition rate that drives bucketing is defined. In particular, queries answered from the result cache are removed even though cache hits are repeated executions by definition, and non-SELECT queries (51.1% of the fleet) are also removed. The paper never states whether the repetition rate used in Sec. 3.4 is computed before or after these filters, nor does it quantify how filtering and the truncation to the first K=1,000 queries of the busiest week change repetition rates and bucket assignments. For example, a user who issues the same query ten times with one cache miss and nine cache hits has a 90% original repetition rate but a 0% post-filter rate under a first-occurrence counting rule. This ambiguity determines whether the benchmark replicates the production workload or a heavily filtered subset, so it must be resolved with explicit definitions and a quantitative sensitivity analysis.
  2. [3.5, 3.6] The claimed exact preservation of query repetition rate is not guaranteed by the Sec. 3.5 algorithm when the fallback strategy is exercised. Step (b) and Step (c) can map a Redset query whose hash has not occurred before to a query instance that has already been used, because the fallback 'randomly pick[s] and reuse[s] one of the query instances from the closest templates.' Such reuse introduces repetitions in the generated workload that do not correspond to repetitions of Redset hashes. Since the fallback is invoked for 18.16% of queries in redbench[imdb] and 17.33% in redbench[tpc-ds], this is not a negligible edge case. The equal-repetition-rate statement in Sec. 3.1 should therefore either be restricted to the portion of the workload not affected by fallback reuse, or the algorithm should be modified so that benchmark-instance repetition exactly tracks Redset-hash repetition, and the resulting 30 workloads' actual repetition rates should be reported.
  3. [3.6, Fig. 2] The only empirical evidence for the workload-drift preservation claim is Fig. 2, which plots cumulative average join counts for a single repetition bucket (80%-90%) and does not report error bars, the number of users, nor the specific low/mid/high-variability selection. The paper claims in the abstract and in Sec. 1 that Redbench reflects distribution shifts and real workload patterns, but no quantitative validation is provided for the other nine buckets or for the 30 individual workloads. At minimum, the authors should show the analogous curves for all ten buckets and report a numeric drift metric (e.g., distribution of per-user repetition rates and join-complexity curves before and after mapping) to substantiate the central claim.
  4. [3.6, Table 1] Section 3.6 concedes that scanset preservation is only best-effort: 31% of remaining Redset users query more tables than are available in either support benchmark, template diversity is insufficient for a bijective scanset mapping, and the fallback reuses or substitutes instances for about 18% of queries. However, table-scan repetitiveness is listed in Table 1 as a required property for clustering and secondary indexing, and Section 4 states that Redbench inherits 'table scan repetitiveness' from Redset. The paper should either scope its contribution to the properties that are actually preserved (query repetition and relative join complexity) or provide a quantitative analysis of how often scansets and scan-level repetitions are distorted under the mapping.
minor comments (5)
  1. [Table 1] The entries 'v0.4' and 'v0.5' in the Redbench column are not defined anywhere in the text; please explain them in the caption or in Sec. 3, or remove them.
  2. [3.4] The aggregation of the two ranks into 'workload-variability' is not specified (e.g., sum of ranks), and tie-breaking is undefined; this makes the selection of the 30 users not fully reproducible.
  3. [3.2] The definition of the busiest week should clarify the timezone of the 8am/5pm boundaries and whether timestamps are normalized per cluster.
  4. [3.6] The sentence 'the remaining repetitions typically represent SELECT queries interspersed with updates' is not supported by a reference or analysis and appears after updates were explicitly excluded in Sec. 3.2; please clarify or remove it.
  5. [Fig. 2] The figure caption refers to 'low- mid- high-variability' but the plot does not show a legend or distinct markers; please label the curves explicitly.

Circularity Check

2 steps flagged · score 6.0 of 10

Two headline 'preservation' claims—query repetition rate and join-complexity curve—reduce by construction to the sampling algorithm's own definitions and matching criteria; Redset itself is an external data source, so the circularity is partial.

  1. self definitional [Section 3.6 'Full Query Repetition' (definition in Sec 3.1; mechanism in Sec 3.5(a))]
    "By construction, Redbench precisely replicates the query repetition rate observed in Redset by mapping identical query hashes to the same benchmark query instances. However, as mentioned earlier, we exclude Redset queries that were answered from the result cache. Consequently, the remaining repetitions typically represent SELECT queries interspersed with updates, a common workload pattern found in business intelligence and dashboarding use cases [27]."

    The query repetition rate is defined in Sec 3.1 as 'the ratio of queries whose hash has already occurred in the timeline.' The sampling algorithm in Sec 3.5(a) says: 'If we have already encountered the query hash, reuse the same benchmark query instance mapped to it.' Therefore equality of the hash-repetition rate between Redset and Redbench is an identity enforced by the algorithm, not an empirically verified preservation. Presenting it as a property of the benchmark that 'precisely replicates' Redset is a restatement of the construction, not a validated finding.

  2. fitted input called prediction [Section 3.6 'Number of Joins' and Fig. 2 (mapping criterion in Sec 3.5(c))]
    "Specifically, the number of joins in each query is normalized during mapping, i.e., the minimum and maximum number of joins in the Redset workload are linearly mapped to the minimum and maximum number of joins in the support benchmark. As shown in Fig. 2, Redbench maintains the shape and structure of the join complexity curve over time despite the shifted absolute numbers."

    The normalized join count is the selection input, not an outcome measured after construction. Sec 3.5(c) chooses templates that 'produce a normalized number of join closest to the normalized number of joins of the user query,' and the min/max linear map is fitted to Redset's range and the support benchmark's range. Consequently, the agreement displayed in Fig. 2 is a consequence of the matching criterion, not independent evidence that Redbench preserves join complexity. The 'preservation' claim is thus equivalent to the fitted parameter that drove the mapping, i.e., a fitted input presented as a confirmed prediction.

full rationale

The central value proposition of Redbench is that its workloads reflect real workload characteristics, especially query repetition and join-complexity drift. The paper's own algorithm makes two of these headline characteristics true by definition: identical hashes are remapped to identical query instances, and templates are selected by normalized join-count closeness. The paper even uses 'By construction' for the repetition claim, acknowledging that the property is engineered rather than empirically discovered. That is a partial circularity because the evidence offered for realism is an identity. The paper's reliance on Redset [27] is load-bearing but not itself circular: Redset is an external empirical analysis of Amazon Redshift workloads, even though one author of the present paper is also a co-author of Redset. The paper also explicitly concedes limitations that reduce realism without being circular: scanset preservation is 'best-effort,' about 18% of queries fall back to random instance reuse, and result-cache queries are removed. These concessions mean the benchmark may not reflect the original production workload's statistics, but that is a completeness/correctness concern rather than a circular-derivation concern. Overall, the repetition and join-complexity 'preservations' reduce by construction, so a score of 6 is appropriate; the benchmark is not fully reduced to a self-citation chain because Redset and the support benchmarks provide independent external content.

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

The central artifact rests on design choices (K, buckets, users per bucket, prefiltering rules) and domain assumptions inherited from Redset and from prior work on support benchmarks. No new entities are introduced.

free parameters (6)
  • K (queries per user) = 1000
    Number of queries retained from the user's busiest week; user-specified, currently 1000. Affects workload length and peak behavior.
  • Number of repetition buckets = 10
    Users partitioned into 10 buckets by query repetition rate (0-10% ... 90-100%), inclusive to the left. Choice affects granularity of user selection.
  • Users per bucket = 3
    Three users sampled per bucket (low, median, high workload-variability), yielding 30 workloads. Choice affects coverage and diversity.
  • Busiest-week definition = Mon 8 am to Fri 5 pm
    Week boundaries used to pick the busiest week for each user; hand-chosen, affects which queries are included.
  • Join-count normalization mapping = linear min-max
    Redset join counts are linearly normalized to the support benchmark's join-count range. Distorts absolute join counts, intended to preserve relative complexity.
  • Prefiltering criteria = SELECT only; exclude result-cache hits; exclude join-less queries; exclude users with min=max joins
    Hand-chosen filters that define the population of Redset queries Redbench models. Excludes over half the fleet's queries.
assumptions (4)
  • domain assumption Redset is a representative sample of production analytical workloads.
    The benchmark's validity rests on Redset's metadata (3 months, 200 clusters) reflecting real workloads; assumed from van Renen et al. [27].
  • domain assumption feature_fingerprint is a valid proxy for query likeness.
    The hash-based repetition detection depends on feature_fingerprint from Redset [27], treated as a reliable signal for query similarity.
  • domain assumption Support benchmarks have sufficient template and instance diversity to approximate Redset workloads.
    Redbench's mapping assumes JOB/CEB and TPC-DS provide enough query templates and instances; the paper notes this holds for 'most well-studied benchmarks' (Sec 3.3).
  • domain assumption Preserving repetition rate, relative join counts, and best-effort scansets is sufficient to capture real workload patterns.
    The paper states Redbench retains 'key workload characteristics' (Sec 3.6) but does not independently validate that these features drive the performance of learned components.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Redbench: A Benchmark Reflecting Real Workloads." pith.science (2026). https://pith.science/paper/E3NOKSIL

@misc{pith2026250612488,
  author       = {Pith},
  title        = {Pith review of: Redbench: A Benchmark Reflecting Real Workloads},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/E3NOKSIL}},
  note         = {Machine review of arXiv:2506.12488}
}
read the original abstract

Instance-optimized components have made their way into production systems. To some extent, this adoption is due to the characteristics of customer workloads, which can be individually leveraged during the model training phase. However, there is a gap between research and industry that impedes the development of realistic learned components: the lack of suitable workloads. Existing ones, such as TPC-H and TPC-DS, and even more recent ones, such as DSB and CAB, fail to exhibit real workload patterns, particularly distribution shifts. In this paper, we introduce Redbench, a collection of 30 workloads that reflect query patterns observed in the real world. The workloads were obtained by sampling queries from support benchmarks and aligning them with workload characteristics observed in Redset.

Figures

Figures reproduced from arXiv: 2506.12488 by the authors.

Figure 1
Figure 1. Sampling and generation using a support bench [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. How Redbench’s sampled workloads preserve Red [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

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

  1. Hollywood: Towards a Large Movie Dataset for Database Benchmarking

    cs.DB 2026-07 conditional novelty 6.0 of 10

    Hollywood is a synthetic IMDb-compatible benchmark generator whose 200K-movie instance induces cardinality-estimation errors comparable to or exceeding the original JOB/IMDb workload, enabling generalization testing b...

  2. Redbench: Workload Synthesis From Cloud Traces

    cs.DB 2025-11 conditional novelty 6.0 of 10

    Redbench synthesizes cloud-shaped SQL workloads from traces and shows that result caching speedups of 1.1–2.98× appear on these workloads while standard JOB/CEB-style baselines show none.

Reference graph

Works this paper leans on

34 extracted references · 28 canonical work pages · cited by 2 Pith papers

  1. [1]

    Günes Aluç, David DeHaan, and Ivan T. Bowman. 2012. Parametric Plan Caching Using Density-Based Clustering. InICDE. IEEE Computer Society, 402–413

    work page 2012

  2. [2]

    2019.What Is Query Store?Apress, Berkeley, CA, 1–29

    Tracy Boggiano and Grant Fritchey. 2019.What Is Query Store?Apress, Berkeley, CA, 1–29. doi:10.1007/978-1-4842-5004-4_1

    work page doi:10.1007/978-1-4842-5004-4_1 2019

  3. [3]

    Franklin, Björn Þór Jónsson, Divesh Srivastava, and Michael Tan

    Shaul Dar, Michael J. Franklin, Björn Þór Jónsson, Divesh Srivastava, and Michael Tan. 1996. Semantic Data Caching and Replacement. InVLDB. Morgan Kaufmann, 330–341

    work page 1996

  4. [4]

    Yanlei Diao, Dominik Horn, Andreas Kipf, Oleksandr Shchur, Ines Benito, Wenjian Dong, Davide Pagano, Pascal Pfeil, Vikram Nathan, Balakrishnan Narayanaswamy, and Tim Kraska. 2024. Forecasting Algorithms for Intelligent Resource Scaling: An Experimental Analysis. InSoCC. ACM, 126–143

    work page 2024

  5. [5]

    Narasayya

    Bailu Ding, Surajit Chaudhuri, Johannes Gehrke, and Vivek R. Narasayya. 2021. DSB: A Decision Support Benchmark for Workload-Driven and Traditional Data- base Systems.Proc. VLDB Endow.14, 13 (2021), 3376–3388

    work page 2021

  6. [6]

    Jialin Ding, Matt Abrams, Sanghita Bandyopadhyay, Luciano Di Palma, Yanzhu Ji, Davide Pagano, Gopal Paliwal, Panos Parchas, Pascal Pfeil, Orestis Polychroniou, Gaurav Saxena, Aamer Shah, Amina Voloder, Sherry Xiao, Davis Zhang, and Tim Kraska. 2024. Automated Multidimensional Data Layouts in Amazon Redshift. InSIGMOD Conference Companion. ACM, 55–67

    work page 2024

  7. [7]

    Dominik Durner, Badrish Chandramouli, and Yinan Li. 2021. Crystal: A Unified Cache Storage System for Analytical Databases.Proc. VLDB Endow.14, 11 (2021), 2432–2444

    work page 2021

  8. [8]

    Narasayya, and Surajit Chaudhuri

    Anshuman Dutt, Chi Wang, Vivek R. Narasayya, and Surajit Chaudhuri. 2020. Efficiently Approximating Selectivity Functions using Low Overhead Regression Models.Proc. VLDB Endow.13, 11 (2020), 2215–2228

    work page 2020

Show all 34 references
  1. [9]

    Jonathan Goldstein and Per-Åke Larson. 2001. Optimizing queries using ma- terialized views: a practical, scalable solution.SIGMOD Rec.30, 2 (May 2001), 331–342. doi:10.1145/376284.375706

    2001

  2. [10]

    Friedman, Yifung Lin, Konstantinos Karanasos, and Sriram Rao

    Alekh Jindal, Shi Qiao, Hiren Patel, Zhicheng Yin, Jieming Di, Malay Bag, Marc T. Friedman, Yifung Lin, Konstantinos Karanasos, and Sriram Rao. 2018. Computa- tion Reuse in Analytics Job Service at Microsoft. InSIGMOD Conference. ACM, 191–203

    2018

  3. [11]

    Boncz, and Alfons Kemper

    Andreas Kipf, Thomas Kipf, Bernhard Radke, Viktor Leis, Peter A. Boncz, and Alfons Kemper. 2019. Learned Cardinalities: Estimating Correlated Joins with Deep Learning. InCIDR. www.cidrdb.org

    2019

  4. [12]

    Franklin, and Gerhard Drasch

    Donald Kossmann, Michael J. Franklin, and Gerhard Drasch. 2000. Cache in- vestment: integrating query optimization and distributed data placement.ACM Trans. Database Syst.25, 4 (2000), 517–558

    2000

  5. [13]

    Yannis Kotidis and Nick Roussopoulos. 1999. DynaMat: A Dynamic View Manage- ment System for Data Warehouses. InSIGMOD Conference. ACM Press, 371–382

    1999

  6. [14]

    Chi, Jeffrey Dean, and Neoklis Polyzotis

    Tim Kraska, Alex Beutel, Ed H. Chi, Jeffrey Dean, and Neoklis Polyzotis. 2018. The Case for Learned Index Structures. InSIGMOD Conference. ACM, 489–504

    2018

  7. [15]

    Boncz, Alfons Kemper, and Thomas Neumann

    Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter A. Boncz, Alfons Kemper, and Thomas Neumann. 2015. How Good Are Query Optimizers, Really?Proc. VLDB Endow.9, 3 (2015), 204–215

    2015

  8. [16]

    Ryan Marcus. 2023. Learned Query Superoptimization. InVLDB Workshops (CEUR Workshop Proceedings, Vol. 3462). CEUR-WS.org

    2023

  9. [17]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Al- izadeh, and Tim Kraska. 2021. Bao: Making Learned Query Optimization Practical. InSIGMOD Conference. ACM, 1275–1288

    2021

  10. [18]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Chi Zhang, Mohammad Alizadeh, Tim Kraska, Olga Papaemmanouil, and Nesime Tatbul. 2019. Neo: A Learned Query Optimizer.Proc. VLDB Endow.12, 11 (2019), 1705–1718

    2019

  11. [19]

    Singh, Zhengchun Liu, Mohammad Rahman, Andreas Kipf, Dominik Horn, Davide Pagano, Gaurav Saxena, Balakrishnan Narayanaswamy, and Tim Kraska

    Vikram Nathan, Vikramank Y. Singh, Zhengchun Liu, Mohammad Rahman, Andreas Kipf, Dominik Horn, Davide Pagano, Gaurav Saxena, Balakrishnan Narayanaswamy, and Tim Kraska. 2024. Intelligent Scaling in Amazon Redshift. InSIGMOD Conference Companion. ACM, 269–279

    2024

  12. [20]

    Parimarjan Negi, Ryan Marcus, Andreas Kipf, Hongzi Mao, Nesime Tatbul, Tim Kraska, and Mohammad Alizadeh. 2021. Flow-Loss: Learning Cardinality Esti- mates That Matter.Proc. VLDB Endow.14, 11 (2021), 2019–2032

    2021

  13. [21]

    Jermaine

    Luis Leopoldo Perez and Christopher M. Jermaine. 2014. History-aware query optimization with materialized intermediate views. InICDE. IEEE Computer Society, 520–531

    2014

  14. [22]

    Tobias Schmidt, Andreas Kipf, Dominik Horn, Gaurav Saxena, and Tim Kraska

  15. [23]

    1999.Materialized view selection for multidimen- sional datasets

    Amit Shukla and Jeff Naughton. 1999.Materialized view selection for multidimen- sional datasets. Ph. D. Dissertation. AAI9939712

    1999

  16. [24]

    Divesh Srivastava, Shaul Dar, H. V. Jagadish, and Alon Y. Levy. 1996. Answering Queries with Aggregation Using Views. InVLDB. Morgan Kaufmann, 318–329

    1996

  17. [25]

    Transaction Processing Performance Council. 2025. TPC-DS Benchmark. https: //www.tpc.org/tpcds/

    2025

  18. [26]

    Transaction Processing Performance Council. 2025. TPC-H Benchmark. https: //www.tpc.org/tpch/

    2025

  19. [27]

    Alexander van Renen, Dominik Horn, Pascal Pfeil, Kapil Vaidya, Wenjian Dong, Murali Narayanaswamy, Zhengchun Liu, Gaurav Saxena, Andreas Kipf, and Tim Kraska. 2024. Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet.Proc. VLDB Endow.17, 11 (2024), 3694–3706

    2024

  20. [28]

    Alexander van Renen and Viktor Leis. 2023. Cloud Analytics Benchmark.Proc. VLDB Endow.16, 6 (2023), 1413–1425

    2023

  21. [29]

    Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. 2020. Building An Elastic Query Engine on Disaggregated Storage. InNSDI. USENIX Association, 449–462

    2020

  22. [30]

    Grisha Weintraub, Ehud Gudes, and Shlomi Dolev. 2024. Coverage-Based Caching in Cloud Data Lakes. InProceedings of the 17th ACM International Systems and Storage Conference(Virtual, Israel)(SYSTOR ’24). Association for Computing Machinery, New York, NY, USA, 193. doi:10.1145/3...

    2024

  23. [31]

    Zongheng Yang, Wei-Lin Chiang, Sifei Luan, Gautam Mittal, Michael Luo, and Ion Stoica. 2022. Balsa: Learning a Query Optimizer Without Expert Demonstrations. InSIGMOD Conference. ACM, 931–944

    2022

  24. [32]

    Rong Zhu, Wei Chen, Bolin Ding, Xingguang Chen, Andreas Pfadler, Ziniu Wu, and Jingren Zhou. 2023. Lero: A Learning-to-Rank Query Optimizer.Proc. VLDB Endow.16, 6 (2023), 1466–1479

    2023

  25. [33]

    Andreas Zimmerer, Damien Dam, Jan Kossmann, Juliane Waack, Ismail Oukid, and Andreas Kipf. 2025. Pruning in Snowflake: Working Smarter, Not Harder. ACM. doi:10.1145/3722212.3724447

    2025

  26. [2024]

    InSIGMOD Conference Companion

    Predicate Caching: Query-Driven Secondary Indexing for Cloud Data Warehouses. InSIGMOD Conference Companion. ACM, 347–359

Pith tools

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