This is Going to Sound Crazy, But What If We Used Large Language Models to Boost Automatic Database Tuning Algorithms By Leveraging Prior History? We Will Find Better Configurations More Quickly Than Retraining From Scratch!

TL;DR

DBMS tuners often struggle to adapt quickly to workload drift and cross-schema changes due to rigid designs that cannot leverage query-level history. Booster integrates with existing tuners by converting historical tuning artifacts into query-specific configurations (QConfigs), using LLMs to derive per-query seeds, and employing a constrained beam-search to compose a holistic configuration. Across OLAP workloads on PostgreSQL, Booster enables tuners to achieve up to large gains in performance and significantly faster re-optimization than re-tuning from history. By enabling per-query semantic reuse and robust composition, Booster generalizes to drift, dataset growth, and hardware changes, offering a practical path to faster, more effective automatic DBMS tuning.

Abstract

Tuning database management systems (DBMSs) is challenging due to trillions of possible configurations and evolving workloads. Recent advances in tuning have led to breakthroughs in optimizing over the possible configurations. However, due to their design and inability to leverage query-level historical insights, existing automated tuners struggle to adapt and re-optimize the DBMS when the environment changes (e.g., workload drift, schema transfer). This paper presents the Booster framework that assists existing tuners in adapting to environment changes (e.g., drift, cross-schema transfer). Booster structures historical artifacts into query-configuration contexts, prompts large language models (LLMs) to suggest configurations for each query based on relevant contexts, and then composes the query-level suggestions into a holistic configuration with beam search. With multiple OLAP workloads, we evaluate Booster's ability to assist different state-of-the-art tuners (e.g., cost-/machine learning-/LLM-based) in adapting to environment changes. By composing recommendations derived from query-level insights, Booster assists tuners in discovering configurations that are up to 74% better and in up to 4.7x less time than the alternative approach of continuing to tune from historical configurations.

Figures (19)

• Figure 1: Tuner Adaptivity Challenges -- PostgreSQL runtimes achieved by tuners in transfer and drift scenarios for three configurations: (1) no re-tune, (2) continue tuning from the best historical configuration for 6hrs and 12hrs, and (3) remix prior knowledge and then tune for 6hrs. Each tuner has access to historical artifacts: TPC-H (transfer) and prior DSB (drift).
• Figure 2: LLM-based Query Adaptation -- DSB workload runtime achieved by prompting an off-the-shelf LLM (WL-Prompt), fine-tuning a LLM with historical knowledge at workload (WL-FT) and query (Q-FT) granularities, and Enrich Q+Compose that combines query prompts enriched with historical attempts and a composition mechanism. All techniques utilize experience generated over 12hrs by a holistic tuner tuning a DSB workload where 50% of queries have different parameters.
• Figure 3: Booster Overview -- The framework integrates with an existing tuner to improve its adaptivity to environment changes. Booster analyzes the artifact repository and injects its findings (e.g., start configuration) into the tuner. The "injected" tuner then refines the configuration and stores its artifacts into the repository for further analysis.
• Figure 4: Booster Architecture -- An overview of the framework's three phases. In Phase I, Booster analyzes historical tuning artifacts. In Phase II, Booster generates candidate configurations (i.e., seeds) for each query with a LLM. In Phase III, Booster then composes each query's seeds into a holistic configuration that it then provides to the tuner being assisted.
• Figure 5: QConfig Construction -- Booster generates QConfig objects from interesting configurations (e.g., configurations that improved the user's objective function): C0, C2, and C5. As Q1-C5 illustrates, each QConfig contains information (e.g., knobs, plan) about a specific query in a configuration, a link to a downstream configuration (e.g., Q1-C2 to Q1-C5), and multiple identity vectors (i.e., embeddings) obtained by passing different schematics through an embedder.