Pith. sign in

REVIEW 3 major objections 5 minor 56 references

A coordinated multi-agent LLM framework can jointly tune knobs, indexes, and materialized views, cutting database latency by up to 38% and tuning time by 57%.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 05:59 UTC pith:WF3IEDAR

load-bearing objection IDSTune is a real first for integrated tuning of knobs, indexes, and materialized views, but its headline gains are measured against hand-assembled sequential baselines and a few arithmetic slips. the 3 major comments →

arxiv 2607.22031 v1 pith:WF3IEDAR submitted 2026-07-24 cs.DB

IDSTune: A Multi-Agent Collaborative Framework for Integrated Database System Tuning

Yiyan Li , Guanli Liu , Renata Borovica-Gajic , Haoyang Li , Zihang Qiu , Xinmei Huang , Andreas Kipf , Cuiping Li
show 1 more author
Hong Chen
This is my paper
classification cs.DB
keywords database tuninglarge language modelsmulti-agent systemsknob configurationindex selectionmaterialized viewsworkload compressionphysical database design
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Database tuning tools usually optimize one knob, index, or materialized view at a time, and chaining separate tools together can backfire because their recommendations conflict. IDSTune is an attempt to tune all three configuration families together using specialized large language model agents coordinated by a supervisor. The paper claims this joint approach avoids harmful interactions, finds globally consistent configurations faster, and adapts to workload and data drift. If right, it points toward a new class of tuning systems that treat the database configuration as one coordinated decision space rather than three independent ones.

Core claim

IDSTune claims to be the first database tuning framework to jointly recommend knobs, indexes, and materialized views in a single coordinated process. It compresses the incoming workload into a compact set of query, data, and system features, then lets three specialist agents—one per configuration component—propose candidate settings. A supervisor agent merges the proposals, rejects conflicting or redundant ones (for instance, a view that duplicates an index or a memory setting that would destabilize the plan), and sends revision instructions until the report is coherent. A safety layer filters invalid configurations before deployment, and the resulting configuration is executed and fed back

What carries the argument

The load-bearing mechanism is a centralized multi-agent loop: specialist agents for knobs, indexes, and materialized views generate proposals; a supervisor agent arbitrates, detects conflicts and redundancies, and requests revisions; and hybrid safety guardrails (rule-based range checks plus LLM-based semantic checks) approve the final configuration. Around this loop sits workload compression—an LLM-based selection agent that picks a small, task-relevant subset of query, data, and system features so prompts stay compact—and optional web search that supplies external domain knowledge. The coordinator's arbitration is what converts three locally sensible recommendations into one globally consi

Load-bearing premise

The headline performance advantage assumes that the comparison baselines—built by chaining existing separate tuners—fairly represent the best available multi-component tuning; if a stronger integrated baseline exists, the reported gap could shrink.

What would settle it

Run IDSTune and the strongest baseline on a workload engineered to contain a known cross-component conflict (e.g., a query where a materialized view plus a raised per-query memory cap flips the optimizer from an index plan to a hash join). If a natively integrated three-component tuner, or even a carefully ordered combination, matches or beats IDSTune's latency within the same tuning budget, the coordination mechanism is not what carries the gains.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • A DBA can tune all three configuration families in one pass, eliminating the need to chain separate knob, index, and view tools.
  • Tuning cost drops because a large share of refinement happens inside the agent dialogue, so fewer expensive workload replays are needed to reach a good configuration.
  • The framework is training-free and feature-based, so it transfers to new hardware and database engines without a retraining phase.
  • Under data and query drift, the tuner degrades less and recovers faster than physical-design-only methods, and it was the only method in the paper's real-world trace with consistently positive gains.
  • The coordination yields a globally consistent final configuration—memory settings that amplify the benefit of indexes and materialized views—rather than a union of local optima.

Where Pith is reading between the lines

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

  • A natural next test is to apply the same supervisor pattern to other configuration families, such as query rewrite rules, table partitioning, or vacuum policies, where optimizer interactions are equally coupled.
  • Because the supervisor's role is mostly conflict detection rather than deep domain expertise, a smaller and cheaper model might play that role while large specialist models generate proposals—a trade-off the paper does not explore.
  • A sharper evaluation will appear once other groups build native three-component tuners; comparing against those, rather than sequenced single-component tools, will isolate how much of the gain comes from the coordination mechanism itself.
  • The interpretable feature-selection and traceable agent dialogue suggest the same machinery could be reused for explaining a chosen configuration or diagnosing performance regressions, not just for generating one.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes IDSTune, an LLM-driven multi-agent framework for jointly tuning three database configuration components: knobs, indexes, and materialized views. The system first compresses workloads into query/data/system features with an LLM-based selection agent, then uses specialist agents (knob, index, view) to propose configurations and a supervisor agent to iteratively resolve conflicts and refine recommendations, with hybrid rule/LLM safety guardrails and optional web search. Experiments on TPC-H, JOB, SDSS, TPC-C, SYSBENCH, Birds, and Redbench compare IDSTune against single-, dual-, and triple-component baselines and report up to 38% latency reduction and 57% faster tuning, with additional ablation, cost, scalability, drift, and cross-engine studies. Code and prompts are publicly available.

Significance. If the results hold, IDSTune is a meaningful step beyond prior work, which has focused on single components or pairs (knob+index, index+view). The paper's claimed contribution—integrated three-component tuning with explicit conflict resolution—is plausible and would be useful for both OLAP and OLTP settings. The evaluation is more thorough than typical systems papers in several respects: five repeated sessions with median/IQR, detailed component ablations, cost analysis, time-budget sensitivity, and robustness to data/query drift. The public release of code and prompt templates is a concrete reproducibility strength. However, the headline quantitative claims rest on comparisons against hand-assembled sequential baselines, since no independent integrated triple tuner exists. The fairness and representativeness of those baselines is the main correctness risk, and at least one reported real-world improvement number is internally inconsistent.

major comments (3)
  1. [§6.1, §6.2] The triple-configuration comparison is the load-bearing support for the abstract's 'up to 38%' and '57% faster' claims, but all three triple baselines are sequential compositions of prior single/pair tuners (UniView→λ-Tune, Proto-X→UniView, AgentTune→HMAB). The text states that these orders 'yield better results than the reverse' but no reverse-order or alternative-composition results are reported. A fair joint-search baseline—one that explores the same three configuration spaces within the same wall-clock budget—could plausibly close much of the gap. Please provide order-sensitivity analysis (at least for the reported orders) or an integrated baseline, or explicitly qualify the claims as being 'vs. sequential compositions' rather than 'vs. state-of-the-art triple tuning.'
  2. [§6.2, SDSS result] The real-world SDSS claim contains an arithmetic inconsistency. The text states IDSTune reduces latency to 465.43 s and outperforms all baselines by an average of 32.7%, but the displayed formula (783.56 − 527.39)/783.56 = 32.7% uses 527.39 s, not 465.43 s. If 465.43 s is the correct final latency, the improvement over the 783.56 s baseline average is 40.6%, not 32.7%. Please correct the formula or clarify what 527.39 represents, and specify which baselines are included in the average.
  3. [§6.5.2] The Single-Agent ablation does not fully address the concern that a competent joint optimizer could outperform the sequential baselines used in §6.2. The Single-Agent variant is a single LLM call without workload compression or iterative revision, so it conflates 'joint search' with 'single-shot monolithic prompting.' To isolate the value of multi-agent specialization, report a variant that performs the same iterative feedback loop with a single unified agent, and ideally a variant with the same workload compression and search budget as the full system.
minor comments (5)
  1. [§6.6.1] The memory-budget experiment is described as 'shown in Figure 11(a)' and 'Figure 11(b)', but those panels belong to the time-budget experiment in §6.6.2. The references should be to Figure 10(a) and Figure 10(b).
  2. [§6.2] The sentence 'On JOB, it achieves at least a 38.3% and 34.7% reduction ... (614.87−379.25/614.87 = 38.3%, 580.66−379.25/580.66 = 34.7%)' is grammatically ambiguous: it is unclear whether the displayed numbers refer to JOB or to TPC-H/SDSS. Please clarify which baselines and benchmarks each percentage refers to.
  3. [Throughout] The name 'Uniview' is used inconsistently with 'UniView' across the baselines section, figure captions, and appendix. Please standardize.
  4. [Table 2] In the 'No Workload' row, '799.5327.59' lacks a separator between the best-found performance and the runtime overhead; it should read '799.53' and '27.59'.
  5. [Appendix A] The text states that Figure A.1 reports per-query execution times and that 'the performance gain ... translate to gains or at least equal performance ... for each single query,' but the figure is not legibly present in the manuscript. Please ensure the figure is included or qualify the claim.

Circularity Check

0 steps flagged

No significant circularity: the claims are empirical measurements against external benchmarks and ablations; self-citations are background, not load-bearing.

full rationale

IDSTune is an empirical systems paper. Its central claims—up to 38% latency reduction and 57% faster tuning, plus consistent superiority across benchmarks—are grounded in measured performance on standard external workloads (TPC-H, JOB, TPC-C, SYSBENCH, SDSS, Birds, Redbench) and in concrete ablations (e.g., Table 3 for multi-agent collaboration, Table 2 for workload compression, Table 4 for guardrails). No equation or derivation defines the reported improvement in terms of a fitted parameter or of the paper's own outputs; the evaluation is externally falsifiable. The triple-configuration baselines are author-assembled combinations of existing methods, but the paper states the composition and order rationale, and this is a baseline-validity threat rather than a circular derivation. Self-citations (AgentTune, E2ETune, LLMIdxAdvis) appear as related work or as one baseline; they do not supply an unverified uniqueness theorem, forbid alternative methods, or define the target result into existence. There is no 'prediction' that is statistically forced by a prior fit, no renaming of a known result, and no ansatz smuggled in solely via self-citation. The closest concern—that no independent integrated triple tuner is compared—concerns generalizability and evaluation design, not circularity. Therefore the paper receives a low score with no specific circular steps identified.

Axiom & Free-Parameter Ledger

5 free parameters · 5 axioms · 4 invented entities

These are engineering components, not speculative physical entities; each is exercised in ablations. The free parameters are protocol/hyperparameter choices selected on the same benchmarks used for the headline claims, so they are disclosed here.

free parameters (5)
  • revision_count = 5
    Maximum supervisor revision iterations; set to 5 because §6.5.4 shows diminishing returns beyond 5 on JOB. This affects token cost and final latency.
  • LLM_inference_temperature = 0
    IDSTune uses temperature 0 (§6.1) to reduce randomness, which affects stability and reproducibility of the reported results.
  • search_mode = Auto
    Web-search mode chosen as default based on ablation §6.5.6; Forced-On performs better but costs more, so Auto is a performance/cost trade-off selected from the evaluation data.
  • improvement_threshold = 5%
    Used in §6.6.2 to decide whether a new configuration is better; this threshold shapes the 'time to best' and convergence comparisons.
  • LLM_backend = GPT-4.1
    Chosen over GPT-5 and Claude-4.7 based on cost/performance trade-off in §6.6.3; the headline results use GPT-4.1, though the framework is tested across models.
axioms (5)
  • domain assumption Knobs, indexes, and materialized views interact; jointly optimizing them is necessary for global performance.
    Motivating example in Fig. 1 and §1 (Query 33b) posits conflicts between work_mem and materialized-view materialization.
  • domain assumption Sequential composition of existing single/pair tuners is a fair representative for multi-component tuning baselines.
    §6.1 constructs UniView+λ-Tune, Proto-X+UniView, and AgentTune+HMAB and uses them as the triple-configuration baselines; if these chains are not representative, the comparison is biased.
  • domain assumption LLM agents can reliably produce and refine syntactically valid configuration candidates given feature-based prompts.
    Phase II relies on parsing LLM outputs; the need for safety guardrails in §5.3 implies this assumption is not always satisfied.
  • domain assumption External web knowledge retrieved on demand improves tuning recommendations.
    Search capability §5.4 is motivated by ReAct; ablation §6.5.6 shows Forced-On improves performance over Forced-Off, providing some empirical support.
  • domain assumption Rule-based constraints plus LLM-based semantic verification are sufficient to prevent invalid configurations.
    §5.3 claims safety; Table 4 shows zero false negatives for the full system on JOB, but no general safety guarantee is proven.
invented entities (4)
  • Specialist Agents (Knob/Index/View) independent evidence
    purpose: Generate per-component configuration candidates in Phase II.
    Ablation Table 3 and Fig. 9(a) show removing them degrades performance; their behavior is testable through the released framework.
  • Supervisor Agent independent evidence
    purpose: Merge specialist outputs, detect conflicts/redundancies, and issue revision instructions until acceptance.
    Ablation Table 3 ('Multi-Agent Non-Collaborative') supports its role; testable as part of the framework.
  • Selection Agent independent evidence
    purpose: Filter workload/query/data/system features per tuning task in Phase I.
    Ablation Table 2 compares Representation+Selection vs. Representation Only vs. No Workload; the agent's effect is empirically falsifiable.
  • Hybrid Safety Guardrails (rule-based + LLM verification) independent evidence
    purpose: Reject invalid or risky configurations before deployment.
    Table 4 reports false negative/positive counts for JOB; the module is testable.

pith-pipeline@v1.3.0-alltime-deepseek · 23920 in / 18142 out tokens · 180669 ms · 2026-08-01T05:59:58.125433+00:00 · methodology

0 comments
read the original abstract

Database tuning is critical for achieving high performance in modern database management systems (DBMSs). Existing methods typically optimize a single component---knobs, indexes, or materialized views---without accounting for their interdependencies. This limitation arises because these components require different tuning strategies and are difficult to integrate within a unified framework. As a result, directly extending a method to multiple components or simply combining separate methods often fails to capture cross-component collaboration and shared tuning signals. Moreover, existing methods are insufficient for handling diverse workloads, evolving data, and dynamic query patterns. To address these limitations, we propose IDSTune, an integrated tuning framework that jointly optimizes multiple configuration components through LLM-driven multi-agent collaboration. IDSTune operates in two phases: (i) workload compression, which extracts and selects task-relevant features, and (ii) configuration recommendation, where specialized agents collaboratively generate and refine configurations for knobs, indexes, and materialized views under the supervision of a centralized coordinator. By incorporating feedback and external knowledge retrieval, IDSTune achieves efficient and globally consistent tuning. Extensive experiments show that IDSTune achieves up to 38% performance improvement and 57% faster tuning, with strong adaptability across diverse scenarios.

Figures

Figures reproduced from arXiv: 2607.22031 by Andreas Kipf, Cuiping Li, Guanli Liu, Haoyang Li, Hong Chen, Renata Borovica-Gajic, Xinmei Huang, Yiyan Li, Zihang Qiu.

Figure 1
Figure 1. Figure 1: Combining UniView (materialized views recommen [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the two phases of IDSTune. In [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Three categories of features in IDSTune. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: IDSTune’s multi-agent collaborative tuning workflow. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Performance comparison of best-found configurations throughout the tuning process across six different benchmarks. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Experiments on different: (a) hardware, and (b) data [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Robustness analysis under progressive data drift. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Experiments on: (a) query drift, and (b) real-world [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Ablation studies on: (a) agent composition, and (b) [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Impact of memory budget on: a) performance and [PITH_FULL_IMAGE:figures/full_fig_p011_10.png] view at source ↗
Figure 13
Figure 13. Figure 13: Time breakdown. rely on any specific LLM. We observe that more powerful models, such as the recently released Claude-4.7, can further improve per￾formance. While it achieves a 19.2% improvement over our primary model, it is around 4× more expensive and has a longer runtime. Nevertheless, we expect that such models will become more cost￾efficient and faster over time. This trend suggests that our approach … view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

56 extracted references · 1 canonical work pages

  1. [1]

    Introducing Dexter, the Automatic Indexer for Postgres — ankane

    2017. Introducing Dexter, the Automatic Indexer for Postgres — ankane. https://medium.com/@ankane/introducing-dexter-the-automatic-indexer-for- postgres-5f8fa8b28f27. Accessed: 2025-10-27

    2017

  2. [2]

    2023. HypoPG. https://hypopg.readthedocs.io/. Accessed: 2025-10-27

    2023

  3. [3]

    pg_hint_plan

    2023. pg_hint_plan. https://github.com/17zhangw/pg_hint_plan/tree/parallel_ patch. Accessed: 2025-10-27

    2023

  4. [4]

    Introducing GPT-5

    2025. Introducing GPT-5. https://openai.com/index/introducing-gpt-5/. Accessed: 2025-10-27

    2025

  5. [5]

    Introducing Claude Opus 4.7

    2026. Introducing Claude Opus 4.7. https://www.anthropic.com/news/claude- opus-4-7. Accessed: 2026-4-18

    2026

  6. [6]

    Bahcall, C

    Kevork Abazajian, Jennifer Adelman-McCarthy, Marcel Agüeros, Sahar Allam, Carlos Prieto, Deokkeun An, Kurt Anderson, Scott Anderson, James Annis, N. Bahcall, C. Bailer-Jones, John Barentine, Bruce Bassett, Andrew Becker, Timothy Beers, Eric Bell, Vasily Belokurov, Andreas Berlind, Eileen Berman, and Daniel Zucker. 2009. The Seventh Data Release of the Slo...

    doi:10.1088/0067- 2009

  7. [7]

    Gordon, and Bohan Zhang

    Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, and Bohan Zhang. 2017. Auto- matic Database Management System Tuning Through Large-scale Machine Learn- ing. In Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD Conference 2017, Chicago, IL, USA, May 14-19, 2017, Semih Salihoglu, Wenchao Zhou, Rada Chirkova, Jun Yang, and D...

    arXiv 2017

  8. [8]

    Anthropic. 2024. Introducing the next generation of Claude. (2024). Available at: https://www.anthropic.com/news/claude-3-family

    2024

  9. [9]

    Elena Baralis, Stefano Paraboschi, and Ernest Teniente. 1997. Materialized Views Selection in a Multidimensional Database. In VLDB’97, Proceedings of 23rd International Conference on Very Large Data Bases, August 25-29, 1997, Athens, Greece, Matthias Jarke, Michael J. Carey, Klaus R. Dittrich, Frederick H. Lochovsky, Pericles Loucopoulos, and Manfred A. J...

    1997

  10. [10]

    Narasayya

    Surajit Chaudhuri and Vivek R. Narasayya. 2007. Self-Tuning Database Systems: A Decade of Progress. In Proceedings of the 33rd International Conference on Very Large Data Bases, University of Vienna, Austria, September 23-27, 2007, Christoph Koch, Johannes Gehrke, Minos N. Garofalakis, Divesh Srivastava, Karl Aberer, Anand Deshpande, Daniela Florescu, Che...

    2007

  11. [11]

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. arXiv:1810.04805 [cs.CL] https://arxiv.org/abs/1810.04805

    Pith/arXiv arXiv 2019

  12. [12]

    Ju Fan, Zihui Gu, Songyue Zhang, Yuxin Zhang, Zui Chen, Lei Cao, Guoliang Li, Samuel Madden, Xiaoyong Du, and Nan Tang. 2024. Combining Small Language Models and Large Language Models for Zero-Shot NL2SQL. Proc. VLDB Endow. 17, 11 (2024), 2750–2763. https://www.vldb.org/pvldb/vol17/p2750-fan.pdf

    2024

  13. [13]

    Michail Georgoulakis Misegiannis, Vasiliki (Verena) Kantere, and Laurent d’Orazio. 2022. Multi-objective query optimization in Spark SQL. In Proceedings of the 26th International Database Engineered Applications Symposium (Bu- dapest, Hungary) (IDEAS ’22). Association for Computing Machinery, New York, NY, USA, 70–74. doi:10.1145/3548785.3548800

    arXiv 2022

  14. [14]

    Victor Giannakouris and Immanuel Trummer. 2025. 𝜆-Tune: Harnessing Large Language Models for Automated Database System Tuning. Proc. ACM Manag. Data 3, 1, Article 2 (Feb. 2025), 26 pages. doi:10.1145/3709652

    doi:10.1145/3709652 2025

  15. [15]

    Google. 2025. Programmable Search Engine: Build and manage a search engine for your site. https://developers.google.com/custom-search. Accessed: 2025-10-27

    2025

  16. [16]

    Major Hayden. 2024. MySQLTuner — A script to review and tune your MySQL installation. https://github.com/major/MySQLTuner-perl. Accessed: 2025-07-22

    2024

  17. [17]

    Xinmei Huang, Haoyang Li, Jing Zhang, Xinxin Zhao, Zhiming Yao, Yiyan Li, Tieying Zhang, Jianjun Chen, Hong Chen, and Cuiping Li. 2025. E2ETune: End-to-End Knob Tuning via Fine-tuned Generative Language Model. arXiv:2404.11581 [cs.AI] https://arxiv.org/abs/2404.11581

    Pith/arXiv arXiv 2025

  18. [18]

    Shrainik Jain, Dominik Moritz, Daniel Halperin, Bill Howe, and Ed Lazowska

  19. [19]

    Tao Ji, Kai Zhong, Luming Sun, Yiyan Li, Cuiping Li, and Hong Chen. 2025. LIOF: Make the Learned Index Learn Faster With Higher Accuracy. IEEE Transactions on Knowledge and Data Engineering 37, 6 (2025), 3499–3513. doi:10.1109/TKDE. 2025.3548298

    arXiv 2025

  20. [20]

    Konstantinos Kanellis, Cong Ding, Brian Kroth, Andreas Müller, Carlo Curino, and Shivaram Venkataraman. 2022. LlamaTune: Sample-Efficient DBMS Con- figuration Tuning. Proc. VLDB Endow. 15, 11 (2022), 2953–2965. doi:10.14778/ 3551793.3551844

    arXiv 2022

  21. [21]

    Alexey Kopytov. 2024. Scriptable database and system performance benchmark. (2024). Available at: https://github.com/akopytov/sysbench/

    2024

  22. [22]

    Jiale Lao, Yibo Wang, Yufei Li, Jianping Wang, Yunjia Zhang, Zhiyuan Cheng, Wanghu Chen, Mingjie Tang, and Jianguo Wang. 2024. GPTuner: A Manual- Reading Database Tuning System via GPT-Guided Bayesian Optimization. Proc. VLDB Endow. 17, 8 (2024), 1939–1952. https://www.vldb.org/pvldb/vol17/p1939- tang.pdf

    2024

  23. [23]

    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. doi:10.14778/2850583.2850594

    arXiv 2015

  24. [24]

    Guoliang Li, Xuanhe Zhou, Shifu Li, and Bo Gao. 2019. QTune: A Query-Aware Database Tuning System with Deep Reinforcement Learning.Proc. VLDB Endow. 12, 12 (2019), 2118–2130. doi:10.14778/3352063.3352129

    arXiv 2019

  25. [26]

    Haoyang Li, Jing Zhang, Hanbing Liu, Ju Fan, Xiaokang Zhang, Jun Zhu, Renjie Wei, Hongyan Pan, Cuiping Li, and Hong Chen. 2024. CodeS: Towards Building Open-source Language Models for Text-to-SQL. Proc. ACM Manag. Data 2, 3 (2024), 127

    2024

  26. [27]

    Yiyan Li. 2025. AgentTune: A Multi-Agent Collaborative Framework for Database Knob Tuning. https://github.com/intlyy/AgentTune/. Accessed: 2025-10-27

    2025

  27. [28]

    Yiyan Li, Haoyang Li, Zhao Pu, Jing Zhang, Xinyi Zhang, Tao Ji, Luming Sun, Cuip- ing Li, and Hong Chen. 2024. Is Large Language Model Good at Database Knob Tuning? A Comprehensive Experimental Evaluation. arXiv:2408.02213 [cs.DB] https://arxiv.org/abs/2408.02213

    Pith/arXiv arXiv 2024

  28. [29]

    Zhaodonghui Li, Haitao Yuan, Jiachen Shi, Hao Zhang, Yu Rong, and Gao Cong

  29. [30]

    Zhaodonghui Li, Haitao Yuan, Huiming Wang, Gao Cong, and Lidong Bing

  30. [31]

    Jie Liu and Barzan Mozafari. 2024. Query Rewriting via Large Language Models. CoRR abs/2403.09060 (2024). arXiv:2403.09060 doi:10.48550/ARXIV.2403.09060

    doi:10.48550/arxiv.2403.09060 2024

  31. [32]

    Microsoft Corporation. 2016. Microsoft SQL Server. https://www.microsoft. com/en-au/sql-server/sql-server-2016

    2016

  32. [33]

    Microsoft Corporation. 2024. Database Engine Tuning Advisorr. https: //learn.microsoft.com/en-us/sql/relational-databases/performance/database- engine-tuning-advisor?view=sql-server-ver17

    2024

  33. [34]

    OpenAI. 2024. Hello gpt-4o. (2024). Available at: https://openai.com/index/hello- gpt-4o/

    2024

  34. [35]

    OpenAI. 2025. Introducing GPT-4.1 in the API. (2025). Available at: https: //openai.com/index/gpt-4-1/

    2025

  35. [36]

    Malinga Perera, Bastian Oetomo, Benjamin I

    R. Malinga Perera, Bastian Oetomo, Benjamin I. P. Rubinstein, and Renata Borovica-Gajic. 2022. HMAB: self-driving hierarchy of bandits for integrated physical database design tuning. Proc. VLDB Endow. 16, 2 (Oct. 2022), 216–229. doi:10.14778/3565816.3565824

    arXiv 2022

  36. [37]

    Tarique Siddiqui and Wentao Wu. 2023. ML-Powered Index Tuning: An Overview of Recent Progress and Open Challenges. arXiv:2308.13641 [cs.DB] https://arxiv. org/abs/2308.13641

    Pith/arXiv arXiv 2023

  37. [38]

    Transaction Processing Performance Council (TPC). 2010. TPC Benchmark C Standard Specification. http://www.tpc.org/tpcc/ Version 5.11.0

    2010

  38. [39]

    Transaction Processing Performance Council (TPC). 2023. TPC Benchmark H Standard Specification. https://www.tpc.org/tpch/ Version 3.2.0

    2023

  39. [41]

    Oleksii Vasyliev. 2024. Pgtune - tuning PostgreSQL config by your hardware. https://github.com/le0pard/pgtune. Accessed: 2025-07-22

    2024

  40. [42]

    Johannes Wehrstein, Roman Heinrich, Mihail Stoian, Skander Krid, Martin Stemmer, Andreas Kipf, Carsten Binnig, and Muhammad El-Hindi. 2025. Red- bench: Workload Synthesis From Cloud Traces. arXiv:2511.13059 [cs.DB] https://arxiv.org/abs/2511.13059 Conference’17, July 2017, Washington, DC, USA Li et al

    Pith/arXiv arXiv 2025

  41. [43]

    Zhenrong Xu, Pengfei Wang, Guoze Xue, Qitong Yan, Shenghao Gong, Yelan Jiang, Yuren Mao, Yunjun Gao, Shu Shen, Wei Zhang, Dan Luo, and Lu Chen

  42. [44]

    Narasimhan, and Yuan Cao

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net. https://openreview. net/forum?id=WE_vluYUL-X

    2023

  43. [45]

    Ji Zhang, Ke Zhou, Guoliang Li, Yu Liu, Ming Xie, Bin Cheng, and Jiashu Xing

  44. [46]

    William Zhang, Wan Shen Lim, Matthew Butrovich, and Andrew Pavlo. 2024. The Holon Approach for Simultaneously Tuning Multiple Components in a Self- Driving Database Management System with Machine Learning via Synthesized Proto-Actions. Proc. VLDB Endow. 17, 11 (July 2024), 3373–3387. doi:10.14778/ 3681954.3682007

    arXiv 2024

  45. [47]

    UniView: A Unified Autonomous Materialized View Management System for Various Databases. Proc. VLDB Endow. 17, 12 (Aug. 2024), 4353–4356. doi:10. 14778/3685800.3685873

    arXiv 2024

  46. [48]

    Xinxin Zhao, Haoyang Li, Jing Zhang, Xinmei Huang, Tieying Zhang, Jianjun Chen, Rui Shi, Cuiping Li, and Hong Chen. 2025. LLMIdxAdvis: Resource-Efficient Index Advisor Utilizing Large Language Model. arXiv:2503.07884 [cs.DB] https: //arxiv.org/abs/2503.07884

    arXiv 2025

  47. [49]

    Xinyang Zhao, Xuanhe Zhou, and Guoliang Li. 2023. Automatic Database Knob Tuning: A Survey. IEEE Trans. Knowl. Data Eng. 35, 12 (2023), 12470–12490. doi:10.1109/TKDE.2023.3266893

    arXiv 2023

  48. [50]

    Yue Zhao, Gao Cong, Jiachen Shi, and Chunyan Miao. 2022. QueryFormer: a tree transformer model for query plan representation. Proc. VLDB Endow. 15, 8 (April 2022), 1658–1670. doi:10.14778/3529337.3529349

    arXiv 2022

  49. [51]

    Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. 2024. D-Bot: Database Diagnosis System using Large Language Models. Proc. VLDB Endow. 17, 10 (2024), 2514–

    2024

  50. [52]

    Xinyi Zhang, Hong Wu, Yang Li, Jian Tan, Feifei Li, and Bin Cui. 2022. Towards Dynamic and Safe Configuration Tuning for Cloud Databases. In SIGMOD ’22: International Conference on Management of Data, Philadelphia, PA, USA, June 12 - 17, 2022, Zachary G. Ives, Angela Bonifati, and Amr El Abbadi (Eds.). ACM, 631–645. doi:10.1145/3514221.3526176

    arXiv 2022

  51. [58]

    Yuqing Zhu, Jianxun Liu, Mengying Guo, Yungang Bao, Wenlong Ma, Zhuoyue Liu, Kunpeng Song, and Yingchun Yang. 2017. BestConfig: tapping the perfor- mance potential of systems via automatic configuration tuning. In Proceedings of the 2017 Symposium on Cloud Computing, SoCC 2017, Santa Clara, CA, USA, September 24-27, 2017. ACM, 338–350. doi:10.1145/3127479...

    arXiv 2017

  52. [2016]

    In Proceedings of the 2016 International Conference on Management of Data (San Francisco, California, USA)(SIGMOD ’16)

    SQLShare: Results from a Multi-Year SQL-as-a-Service Experiment. In Proceedings of the 2016 International Conference on Management of Data (San Francisco, California, USA)(SIGMOD ’16). Association for Computing Machinery, New York, NY, USA, 281–293. doi:10.1145/2882903.2882957

    arXiv 2016

  53. [2021]

    CDBTune: An efficient deep reinforcement learning-based automatic cloud database tuning system. VLDB J. 30, 6 (2021), 959–987. doi:10.1007/S00778-021- 00670-9

    work page doi:10.1007/s00778-021- 2021

  54. [2024]

    CoRR abs/2404.12872 (2024)

    LLM-R2: A Large Language Model Enhanced Rule-based Rewrite System for Boosting Query Efficiency. CoRR abs/2404.12872 (2024). arXiv:2404.12872 doi:10.48550/ARXIV.2404.12872

    Pith/arXiv arXiv doi:10.48550/arxiv.2404.12872 2024

  55. [2025]

    arXiv:2508.16044 [cs.DB] https://arxiv.org/abs/2508.16044

    AMAZe: A Multi-Agent Zero-shot Index Advisor for Relational Databases. arXiv:2508.16044 [cs.DB] https://arxiv.org/abs/2508.16044

    arXiv

  56. [2527]

    https://www.vldb.org/pvldb/vol17/p2514-li.pdf