Pith. sign in

REVIEW 5 major objections 5 minor 39 references

PBench: Workload Synthesizer with Real Statistics for Cloud Analytics Benchmarking

T0 review · 5 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 PBench claims that anonymized cloud workload traces, which contain execution statistics but no SQL or data, can be turned into executable synthetic workloads that closely reproduce those statistics, cutting approximation error by up to 6×…

desk verdict PBench is a genuinely new and well-engineered workload synthesis pipeline for cloud analytics benchmarking, but the evaluation needs transparency on LLM, error bars, and a direct test of the additivity assumption. read the letter →

arxiv 2506.16379 v1 pith:RL2NE6KV submitted 2025-06-19 cs.DB

Yan Zhou , Chunwei Liu , Bhuvan Urgaonkar , Zhengle Wang , Magnus Mueller , Chao Zhang , Songyue Zhang , Pascal Pfeil
show 6 more authors
Dominik Horn Zhengchun Liu Davide Pagano Tim Kraska Samuel Madden Ju Fan
This is my paper · ORCID
classification cs.DB
keywords workloadsynthesiscloudanalyticsbenchmarkingtracesintegerlinearprogrammingsimulatedannealingLLMquerygenerationoperatordistributionsperformancemetrics
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

The paper introduces a new problem: turning anonymized cloud workload traces, which contain performance metrics and operator distributions but no SQL or underlying databases, into synthetic workloads that reproduce those statistics when executed. PBench solves this by selecting and combining queries and databases from existing benchmarks, assigning timestamps to preserve temporal dynamics, and augmenting the candidate set with LLM-generated components. The authors claim this reduces approximation error by up to 6 times compared to prior synthesis tools like Stitcher and CAB. If correct, PBench lets cloud vendors and researchers benchmark and tune database systems on realistic, privacy-preserving workloads derived from real production statistics.

What carries the argument

The central object is the workload component—a benchmark query paired with its populated database—with profiled performance features. The argument is carried by an integer linear program (ILP) whose objective is the sum of relative errors between the synthesized and real window-level performance features, solved to choose repetition counts of each component; a simulated annealing pass that refines query start times to match interval-level CPU time and scanned bytes; and an LLM augmentation loop that generates new components from centroid targets, using nearest and farthest examples as hints and trial-and-error regeneration.

What would settle it

Take a real trace dominated by a few very large queries whose resource consumption does not split linearly across benchmark components (e.g., a query whose cost is dominated by a single hash join with a large memory footprint), synthesize a workload with PBench, and compare the replayed CPU time and scanned bytes to the trace; if the GMAPE exceeds the reported range even with augmentation, the additivity and transfer assumptions fail in a detectable way.

Watch

Extended reading notes

Core claim

PBench claims that the statistics of a real cloud workload can be closely approximated by a carefully chosen mixture of profiled benchmark components, even though the original queries and data are unknown. Component selection is cast as an integer linear program that minimizes relative error across both performance metrics (CPU time, scanned bytes) and operator distributions (filter, aggregate, join, sort ratios), subject to duration, diversity, and count constraints. A simulated-annealing step then assigns timestamps to the selected components under a linear concurrency slowdown model to match the target's temporal peaks and valleys at fine intervals. When benchmark components cannot cover the target statistics, an LLM-based augmenter generates new queries on existing or rescaled databases, guided by positive and negative examples and iterative profiling feedback. On Snowset and Redset traces, PBench reports up to 6× lower approximation error than Stitcher and CAB.

Load-bearing premise

The whole construction assumes the performance features of a mixture are the weighted sum of individually profiled components, so if queries interact nonlinearly under concurrency or profiling costs do not transfer to the target cluster, the selected workload will not reproduce the target statistics.

Editorial extensions

If this is right

  • Cloud vendors can release executable benchmarks derived from their anonymized traces without exposing customer SQL or data, since only statistics are used.
  • Database optimizers and cost models can be evaluated on workloads whose operator distributions match production, potentially changing which join and aggregation strategies are chosen.
  • The synthesis is fast enough—about 14 minutes per one-hour trace—to support near-real-time workload replay, making it practical for continuous benchmarking.
  • Query-level synthesis with one-to-many ILP matching outperforms one-to-one matching, suggesting workload combination, not single-query mimicry, is the right granularity.

Reading between the lines

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

  • Editorial inference: The additivity assumption behind the ILP could be stress-tested by synthesizing workloads that deliberately combine components with known nonlinear interactions (e.g., memory-bound joins competing for cache); if the error grows with interaction strength, the objective would need interaction terms.
  • Editorial inference: The LLM augmentation step is not specific to TPC-H or TPC-DS; it could generate components for other benchmarks or domain-specific schemas, provided profiling feedback is available, which would extend the method to workloads with unusual operator mixes.
  • Editorial inference: Because the method only needs aggregated statistics, it could be applied to traces collected at coarser granularity (e.g., minute-level logs) or to metrics like memory and IOPS, assuming those features are also additive.
  • Editorial inference: If many vendors adopt this approach, benchmark-based research could shift from fixed TPC workloads to trace-driven workload synthesis, changing how experimental sections of database papers are designed.
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

5 major / 5 minor

Summary. The paper introduces PBench, a workload synthesizer that takes real cloud workload traces (Snowset, Redset), which contain execution statistics but no SQL or databases, and constructs an executable synthetic workload from benchmark components (TPC-H, TPC-DS, JOB, YCSB). The synthesis pipeline has three stages: an ILP-based component selection that jointly minimizes relative error for performance metrics and operator distributions, a simulated-annealing timestamp assignment phase that refines the temporal placement of selected components, and an LLM-based component augmentation step that generates new queries and databases to close the gap between benchmark components and target traces. The paper evaluates PBench on Snowset and Redset against CAB and Stitcher, reporting substantially lower approximation error, with up to a 6x reduction in GMAPE for CPU Time, and it releases artifacts on GitHub.

Significance. The problem is timely and practical: anonymized cloud traces are increasingly available, but they cannot be executed directly, and existing benchmark-based synthesizers like CAB and Stitcher either use coarse heuristics or ignore operator distributions. If the reported results hold, PBench would be a useful tool for turning real trace statistics into replayable, privacy-preserving benchmarks. The paper deserves credit for formulating the synthesis problem precisely, providing a detailed ILP/SA/LLM pipeline, evaluating on two real traces, and open-sourcing the code. I do not see a hidden circularity in the main evaluation: the error metrics are computed from actually replayed synthetic workloads, not from the ILP objective alone. However, the quantitative claims currently rest on an undisclosed LLM, on stochastic experiments reported without variance, and on a baseline comparison whose candidate pools may not be matched; these issues are fixable but they block acceptance as-is.

major comments (5)
  1. [Section 5 and Section 6.1 (footnote 1)] The LLM augmenter is described only as "a state-of-the-art LLM model" with the model name withheld due to Amazon policy. Since component augmentation is one of the three core stages and the ablation study shows it has a large effect on operator-ratio accuracy, the experimental results are not reproducible without disclosing the model, the model version, and the decoding parameters (temperature, max tokens, prompt format). Please provide this information or a reproducible API-based alternative.
  2. [Section 6.2 and Tables 3-6] The evaluation involves multiple sources of randomness: random selection of one-hour traces from Snowset, stochastic simulated annealing, and nondeterministic LLM generation, yet all tables report a single run with no error bars or confidence intervals. This is particularly concerning in Table 3, where PBench reports exactly 0.00 MAE for all four operator ratios; the reader cannot tell whether this is rounding, an exact fit, or an artifact of the aggregation. Please report means and standard deviations over repeated runs and clarify the exact-zero values.
  3. [Section 6.1, Baseline setup] For CAB, the paper states that "we use all our prepared workload components queries to construct the query pool for a fair comparison," but the LLM-generated components are introduced as part of PBench's augmentation stage. If CAB and Stitcher did not receive the same augmented candidate pool, the comparison conflates the effect of the synthesis algorithm with the effect of the enlarged and better-matched candidate set. Please rerun the baselines with the identical augmented pool, or clearly state which candidate pool each method used and justify the asymmetry.
  4. [Section 4.1.1, Eq. (1)] The ILP objective sums individually profiled component features (CPU time, scanned bytes, operator counts), which assumes that the aggregate statistics of concurrently running queries equal the sum of single-query profiles. Section 4.2.1 acknowledges that parallel execution changes per-query execution times and patches only the timestamp phase with a linear slowdown model, but the paper never isolates whether the additive selection assumption degrades aggregate fidelity under concurrency. The end-to-end replay results are encouraging, but the paper should add a predicted-vs-actual error decomposition at the window level, similar to the query-level decomposition in Figure 9, and report whether the error grows with concurrency or with the degree to which the selected workload deviates from the sum-of-parts assumption.
  5. [Section 6.1, Eq. (3)] As printed, the GMAPE formula uses an exponent of 1/(n-1) and has no final "-1", which is not the standard geometric-mean absolute percentage error. If the formula was implemented literally, all GMAPE values in Tables 3, 4, 6, and 8 would be computed incorrectly. Please correct the equation and verify the reported numbers, or explicitly define the intended statistic if a nonstandard metric is used.
minor comments (5)
  1. [Section 2, opening sentence] "This section first some presents background information" is ungrammatical; revise to "This section first presents background information."
  2. [Section 6.2, Efficiency Evaluation] "Therfore" should be "Therefore."
  3. [Section 2.2 and Eq. (1)] The definition of O as a "percentage distribution" conflicts with the additive use of o'_uj in Eq. (1), which treats operator counts (e.g., "Agg Num" in Figure 4) as quantities that can be summed. Please clarify whether the objective operates on ratios, counts, or both, since this affects how the operator terms should be normalized.
  4. [Section 3.2.2] Profiling each query three times and averaging is a reasonable cache-handling strategy, but the paper does not report the variance across the three runs; a brief statement on run-to-run variability would help the reader judge the reliability of the profiled features.
  5. [Section 6.1, Hyperparameter settings] The K-Means centroid count k used in Section 5 is not listed among the hyperparameters. Please specify k and, ideally, report sensitivity of the augmentation stage to this parameter.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: PBench optimizes exactly the trace-matching objective it evaluates, and its reported errors come from actual replays rather than from the optimization objective itself.

full rationale

PBench's derivation chain is a workload-reconstruction pipeline, not a hidden prediction chain. Equation (1) minimizes the relative error between a linear combination of profiled component features and the target window statistics; this objective is the formal definition of the workload-synthesis task (Definition 2.4), and the paper evaluates the result by executing the synthesized workload and measuring replay statistics (Figures 6-9), so the reported errors are not merely the ILP objective values. No term in Eq. (1) is defined in terms of the output workload, and the decision variables are repetition counts of benchmark components, not parameters that encode the target statistics. The LLM augmentation in Section 5 uses target-window centroids as generation goals and later measures error on the same windows; this is in-sample fitting rather than out-of-sample prediction, and the paper does not claim generalization to unseen traces. The only overlapping-author citation is the Auto-WLM linear-slowdown assumption in Section 4.2.1, introduced as 'Following [27], we assume that an additional query linearly slows down existing queries'; it is an explicitly stated modeling assumption, it is externally motivated, and the paper concedes its limits ('completely eliminating such mismatches is infeasible'). It is not the source of the headline 6x claim and does not make the derivation circular. The uniform-distribution aggregation used to build interval-level targets (Section 3.2.1) is an acknowledged validity caveat that applies to all compared methods, not a step that reduces a claimed result to its own inputs. Overall, the paper is self-contained against external traces (Snowset, Redset) and external baselines (CAB, Stitcher), so the honest finding is no significant circularity.

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

The central claim rests on several domain assumptions common to workload synthesis: additivity of profiled component features, a linear slowdown model for concurrency, uniform aggregation of query statistics, cluster similarity, and the sufficiency of LLM-generated components. No new physical or conceptual entities are introduced. The free parameters are empirical hyperparameters for time windows, ILP constraints, SA termination, and LLM target selection.

free parameters (6)
  • time_window_length_Gamma = 5 minutes
    Set empirically to balance selection space and timestamp accuracy (Section 3.2.1, Section 6.1).
  • time_interval_length_gamma = 30 seconds
    Set empirically as the fine-grained interval for timestamp assignment (Section 6.1).
  • diversity_constraint_y = 10
    Limits repetitions of each workload component (Section 6.1).
  • total_count_constraint_z = 2x original query count
    Sets maximum number of components per window (Section 6.1).
  • SA_stopping_steps_S = 100
    No-improvement step count for simulated annealing (Section 6.1).
  • LLM_kmeans_centroid_count_k = not reported
    Number of generation targets in LLM augmentation; value not specified in the paper (Section 5, Step 1).
assumptions (5)
  • domain assumption Performance features combine additively: total CPU time, scanned bytes, and operator counts equal the sum over selected components (Eq. 1).
    The ILP objective in Section 4.1.1 assumes linear additivity of component profiles and ignores concurrency interactions during selection.
  • domain assumption Concurrent queries slow each other down linearly (Section 4.2.1).
    Timestamp assignment estimates query durations using a linear slowdown model from [27].
  • domain assumption Query-level statistics can be aggregated into time intervals via a uniform distribution (Section 3.2.1).
    Used to convert per-query metrics to interval-level targets when actual query durations are unknown.
  • domain assumption Source and target clusters are sufficiently similar (Section 2.2, Remarks).
    The framework assumes matching node count, machine configuration, and DBMS between the trace's origin and the testbed.
  • domain assumption LLM-generated queries on benchmark databases can span the space of customer query characteristics.
    The augmentation stage assumes the LLM can produce queries with target performance features via trial-and-error; the LLM itself is a black box and undisclosed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PBench: Workload Synthesizer with Real Statistics for Cloud Analytics Benchmarking." pith.science (2026). https://pith.science/paper/RL2NE6KV

@misc{pith2026250616379,
  author       = {Pith},
  title        = {Pith review of: PBench: Workload Synthesizer with Real Statistics for Cloud Analytics Benchmarking},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RL2NE6KV}},
  note         = {Machine review of arXiv:2506.16379}
}
read the original abstract

Cloud service providers commonly use standard benchmarks like TPC-H and TPC-DS to evaluate and optimize cloud data analytics systems. However, these benchmarks rely on fixed query patterns and fail to capture the real execution statistics of production cloud workloads. Although some cloud database vendors have recently released real workload traces, these traces alone do not qualify as benchmarks, as they typically lack essential components like the original SQL queries and their underlying databases. To overcome this limitation, this paper introduces a new problem of workload synthesis with real statistics, which aims to generate synthetic workloads that closely approximate real execution statistics, including key performance metrics and operator distributions, in real cloud workloads. To address this problem, we propose PBench, a novel workload synthesizer that constructs synthetic workloads by judiciously selecting and combining workload components (i.e., queries and databases) from existing benchmarks. This paper studies the key challenges in PBench. First, we address the challenge of balancing performance metrics and operator distributions by introducing a multi-objective optimization-based component selection method. Second, to capture the temporal dynamics of real workloads, we design a timestamp assignment method that progressively refines workload timestamps. Third, to handle the disparity between the original workload and the candidate workload, we propose a component augmentation approach that leverages large language models (LLMs) to generate additional workload components while maintaining statistical fidelity. We evaluate PBench on real cloud workload traces, demonstrating that it reduces approximation error by up to 6x compared to state-of-the-art methods.

Figures

Figures reproduced from arXiv: 2506.16379 by the authors.

Figure 1
Figure 1. An Example Workload Trace from Redset. statistics, including a performance metric, CPU Time, and an oper￾ator distribution feature, Join Number. Leveraging these traces presents an opportunity to develop benchmarks that better reflect real-world cloud database workloads. However, these traces alone do not constitute benchmarks, as they typically lack essential components like the original SQL queries and their under… view at source ↗
Figure 2
Figure 2. Workload Synthesis with Real Statistics. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Overall Framework of PBench that consists of three stages: (1) PBench prepares workload components from stan￾dard benchmarks. (2) PBench employs a two-phase workload synthesis approach to generate the workload by selecting and combining components to approximate real workload statistics. (3) PBench augments workload components to further improve approximation effectiveness. problem is to synthesize a workload 𝑊e suc… view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Two Phase Workload Synthesis the system, thus obtaining the estimated duration of all queries in the system at this time. 4.2.2 Simulated Annealing. To achieve a fine-grained generation, we model the timestamp assignment problem as an optimization problem, and the opti…
Figure 5
Figure 5. Figure 5: LLM-enhanced Workload Augmentation Step 2: Example retrieval. Due to LLM’s inability to directly understand the relationship between queries and their performance features in a zero-shot scenario, we need to provide LLM with infor￾mative cases for each generation targe…
Figure 6
Figure 6. Figure 6: Replayed Traces on Snowset with Different Methods [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Ablation Study Replayed Traces on Snowset [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Replayed Traces on Redset [PITH_FULL_IMAGE:figures/full_fig_p012_8.png]
Figure 9
Figure 9. Figure 9: Error Evaluation Results on Redset (Query Level) [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 28 canonical work pages

  1. [1]

    Nikos Armenatzoglou, Sanuj Basu, Naga Bhanoori, Mengchu Cai, Naresh Chainani, Kiran Chinta, Venkatraman Govindaraju, Todd J Green, Monish Gupta, Sebastian Hillig, et al. 2022. Amazon Redshift re-invented. InProceedings of the 2022 International Conference on Management of Data. 2205–2217

    work page 2022

  2. [2]

    Jinsheng Ba and Manuel Rigger. 2024. Keep It Simple: Testing Databases via Differential Query Plans.Proceedings of the ACM on Management of Data2, 3 (2024), 1–26

    work page 2024

  3. [3]

    Peter Boncz, Angelos-Christos Anatiotis, and Steffen Kläbe. 2018. JCC-H: Adding Join Crossing Correlations with Skew to TPC-H. InPerformance Evaluation and Benchmarking for the Analytics Era, Raghunath Nambiar and Meikel Poess (Eds.). Springer International Publishing, Cham, 103–119

    work page 2018

  4. [4]

    Peter Boncz, Thomas Neumann, and Orri Erling. 2013. TPC-H analyzed: Hidden messages and lessons learned from an influential benchmark. InTechnology Conference on Performance Evaluation and Benchmarking. Springer, 61–76

    2013

  5. [5]

    Nicolas Bruno, Surajit Chaudhuri, and Dilys Thomas. 2006. Generating queries with cardinality constraints for dbms testing.IEEE Transactions on Knowledge and Data Engineering18, 12 (2006), 1721–1725

    work page 2006

  6. [6]

    Brian F Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. 2010. Benchmarking cloud serving systems with YCSB. InProceedings of the 1st ACM symposium on Cloud computing. 143–154

    2010

  7. [7]

    Benoit Dageville, Thierry Cruanes, Marcin Zukowski, Vadim Antonov, Artin Avanes, Jon Bock, Jonathan Claybaugh, Daniel Engovatov, Martin Hentschel, Jiansheng Huang, et al. 2016. The snowflake elastic data warehouse. InProceed- ings of the 2016 International Conference on Management of Data. 215–226

    2016

  8. [8]

    Shaleen Deep, Anja Gruenheid, Kruthi Nagaraj, Hiro Naito, Jeff Naughton, and Stratis Viglas. 2021. Diametrics: benchmarking query engines at scale.ACM SIGMOD Record50, 1 (2021), 24–31

    work page 2021

Show all 39 references
  1. [9]

    Akon Dey, Alan Fekete, Raghunath Nambiar, and Uwe Röhm. 2014. YCSB+ T: Benchmarking web-scale transactional databases. In2014 IEEE 30th International Conference on Data Engineering Workshops. IEEE, 223–230

    2014

  2. [10]

    Haowen Dong, Chao Zhang, Guoliang Li, and Huanchen Zhang. 2024. Cloud- Native Databases: A Survey.IEEE Transactions on Knowledge and Data Engineer- ing(2024)

    2024

  3. [11]

    Markus Dreseler, Martin Boissier, Tilmann Rabl, and Matthias Uflacker. 2020. Quantifying TPC-H choke points and their optimizations.Proceedings of the VLDB Endowment13, 8 (2020), 1206–1220

    2020

  4. [12]

    John Forrest and Robin Lougee-Heimer. [n.d.]. CBC User Guide. https://www. coin-or.org/Cbc/. 2024/12/13

    2024

  5. [13]

    Peter I Frazier. 2018. A tutorial on Bayesian optimization.arXiv preprint arXiv:1807.02811(2018)

    2018 arXiv

  6. [14]

    Jacob R Gardner, Matt J Kusner, Zhixiang Eddie Xu, Kilian Q Weinberger, and John P Cunningham. 2014. Bayesian optimization with inequality constraints.. InICML, Vol. 2014. 937–945

    2014

  7. [15]

    IMDb. 2024. IMDb Non-Commercial Datasets. https://developer.imdb.com/non- commercial-datasets/. 2024/12/13

    2024

  8. [16]

    Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2015. How good are query optimizers, really?Proceedings of the VLDB Endowment9, 3 (2015), 204–215

    2015

  9. [17]

    Viktor Leis and Maximilian Kuschewski. 2021. Towards cost-optimal query processing in the cloud.Proceedings of the VLDB Endowment14, 9 (2021), 1606– 1612

    2021

  10. [18]

    Guoliang Li, Haowen Dong, and Chao Zhang. 2022. Cloud databases: New techniques, challenges, and opportunities.Proceedings of the VLDB Endowment 15, 12 (2022), 3758–3761

    2022

  11. [19]

    Guoliang Li, Xuanhe Zhou, and Lei Cao. 2021. Machine learning for databases. InProceedings of the First International Conference on AI-ML Systems. 1–2

    2021

  12. [20]

    Zhaodonghui Li, Haitao Yuan, Huiming Wang, Gao Cong, and Lidong Bing. 2024. LLM-R2: A Large Language Model Enhanced Rule-based Rewrite System for Boosting Query Efficiency.arXiv preprint arXiv:2404.12872(2024)

    2024 arXiv

  13. [21]

    Microsoft. 2024. DSB benchmark. https://github.com/microsoft/dsb. 2024/12/13

    2024

  14. [22]

    Chaitanya Mishra, Nick Koudas, and Calisto Zuzarte. 2008. Generating targeted queries for database testing. InProceedings of the 2008 ACM SIGMOD international conference on Management of data. 499–510

    2008

  15. [23]

    Magnus Müller, Lucas Woltmann, and Wolfgang Lehner. 2023. Enhanced Fea- turization of Queries with Mixed Combinations of Predicates for ML-based Cardinality Estimation.. InEDBT. 273–284

    2023

  16. [24]

    Fernando Nogueira. 2014–. Bayesian Optimization: Open source constrained global optimization tool for Python. https://github.com/bayesian-optimization/ BayesianOptimization

    2014

  17. [25]

    Meikel Poess, Raghunath Othayoth Nambiar, and David Walrath. 2007. Why You Should Run TPC-DS: A Workload Analysis.. InVLDB, Vol. 7. 1138–1149

    2007

  18. [26]

    Prometheus. 2024. Prometheus Github Page. https://github.com/prometheus. 2024/12/13

    2024

  19. [27]

    Gaurav Saxena, Mohammad Rahman, Naresh Chainani, Chunbin Lin, George Caragea, Fahim Chowdhury, Ryan Marcus, Tim Kraska, Ippokratis Pandis, and Balakrishnan (Murali) Narayanaswamy. 2023. Auto-WLM: Machine Learning Enhanced Workload Management in Amazon Redshift. InCompanion of ...

    2023

  20. [28]

    Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. 2017. Automatic database management system tuning through large-scale machine learning. InProceedings of the 2017 ACM international conference on management of data. 1009–1024

    2017

  21. [29]

    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. Proceedings of the VLDB Endowment17, 11 (2024),...

    2024

  22. [30]

    Alexander Van Renen and Viktor Leis. 2023. Cloud analytics benchmark.Pro- ceedings of the VLDB Endowment16, 6 (2023), 1413–1425

    2023

  23. [31]

    Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. 2020. Building an elastic query engine on disaggregated storage. In17th USENIX Symposium on Networked Systems Design and Implemen- tation (NSDI 20). 449–462

    2020

  24. [32]

    Richard J. Wagner. 2024. Python module for simulated annealing. https://github. com/perrygeo/simanneal. 2024/12/13

    2024

  25. [33]

    Ciortea, Konstantinos Karanasos, and Subru Krishnan

    Chengcheng Wan, Yiwen Zhu, Joyce Cahoon, Wenjing Wang, Katherine Lin, Sean Liu, Raymond Truong, Neetu Singh, Alexandra M. Ciortea, Konstantinos Karanasos, and Subru Krishnan. 2023. Stitcher: Learned Workload Synthesis from Historical Performance Footprints. InEDBT. OpenProceed...

    2023 doi

  26. [34]

    2023.MTD-DS: an SLA-aware Decision Support Benchmark for Multi-tenant Parallel DBMSs

    Shaoyi Yin, Franck Morvan, Jorge Martinez-Gil, and Abdelkader Hameurlain. 2023.MTD-DS: an SLA-aware Decision Support Benchmark for Multi-tenant Parallel DBMSs. Ph.D. Dissertation. IRIT-Institut de Recherche en Informatique de Toulouse

    2023

  27. [35]

    Chao Zhang, Guoliang Li, and Tao Lv. 2024. HyBench: A New Benchmark for HTAP Databases.Proceedings of the VLDB Endowment17, 5 (2024), 939–951

    2024

  28. [36]

    Chao Zhang, Guoliang Li, Jintao Zhang, Xinning Zhang, and Jianhua Feng

  29. [37]

    Huanchen Zhang, Yihao Liu, and Jiaqi Yan. 2023. Cost-Intelligent Data Analytics in the Cloud.arXiv preprint arXiv:2308.09569(2023)

    2023 arXiv

  30. [38]

    Lixi Zhang, Chengliang Chai, Xuanhe Zhou, and Guoliang Li. 2022. Learnedsql- gen: Constraint-aware sql generation using reinforcement learning. InProceed- ings of the 2022 International Conference on Management of Data. 945–958. 13

    2022

  31. [2024]

    HTAP Databases: A Survey.IEEE Transactions on Knowledge and Data Engineering(2024)

    2024

Pith tools

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