arXiv CSopen access

A Case for Agentic Tuning: From Documentation to Action in PostgreSQL

A Case for Agentic Tuning: From Documentation to Action in PostgreSQL

arXiv:2605.19988v1 [cs.SE] 19 May 2026

Hongyu Lin∗ Institute of Software, Chinese Academy of Sciences University of Chinese Academy of Sciences [email protected] Mingyu Li∗ Key Laboratory of System Software (Chinese Academy of Sciences) Institute of Software, Chinese Academy of Sciences University of Chinese Academy of Sciences [email protected] Weichen Zhang Beihang University [email protected]

Yihang Lou Peking University [email protected]

Mingjie Xing Institute of Software, Chinese Academy of Sciences University of Chinese Academy of Sciences [email protected] Yanjun Wu Institute of Software, Chinese Academy of Sciences University of Chinese Academy of Sciences [email protected] Haibo Chen Key Laboratory of System Software (Chinese Academy of Sciences) Institute of Software, Chinese Academy of Sciences Shanghai Jiao Tong University [email protected]

Abstract Documentation has long guided computer system tuning by distilling expert knowledge into per-parameter recommendations. Yet such guides capture only what experts conclude, discarding how they reason. This fundamental gap manifests in three concrete deficiencies: documentation grows stale as software evolves, fails under heterogeneous workloads, and ignores inter-parameter dependencies. We propose shifting from static documentation to dynamic action for system tuning. We introduce P ERF E VOLVE, which translates expert tuning methodologies into executable skills that equip LLM-based agents to perform version-consistency verification, workload-specific profiling, and multi-parameter joint optimization. ∗ These authors contributed equally.

Preprint.

Evaluated on PostgreSQL under TPC-C and TPC-H benchmarks, P ERF E VOLVE outperforms state-of-the-art documentation-driven tuning baselines by up to 35.2%. The tool is available at https://github.com/ISCAS-OSLab/PerfEvolve.

1

Introduction

Modern computer systems, from operating systems [5, 31, 1] to database systems [40, 34, 3, 32], expose hundreds of configurable parameters that govern their runtime behavior. These parameters control everything from memory allocation to I/O scheduling to concurrency policies. Collectively, they define a vast configuration space whose optimal point shifts with hardware generations, workload characteristics, and deployment scale. Navigating this space well can yield order-of-magnitude performance improvements [23, 36, 37, 60]; navigating it poorly leads to resource waste, latency spikes, and missed service-level objectives. Historically, system operators have relied on documentation as the primary source for tuning expertise: official reference manuals, community-maintained guides, and the built-in rule sets embedded in dedicated tuning tools [49, 55, 14, 47, 2, 4, 33]. Documentation encodes the expertise of system developers and practitioners, distilling years of benchmarking and field observation into recommended defaults, safe operating ranges, and cautionary notes. In a sense, it is the externalized long-term knowledge of the systems community [8, 10, 24]. The advent of large language models (LLMs) has opened a new frontier in automated tuning. Recent work has proposed feeding documentation directly to LLMs to construct informed priors over the parameter space [48, 15, 46]. State-of-the-art systems such as GPTuner [26] exemplifies this paradigm: it ingests official manuals and community guides, uses LLMs to extract parameter semantics and value constraints, and injects the resulting knowledge into a Bayesian optimization loop [57], which significantly narrows the search space compared to uninformed baselines. However, this line of work rests on an implicit assumption that documentation is sufficiently correct. When this assumption is flawed, improvements are bounded by the quality of the documentation itself. Through a systematic analysis of documentation for various production systems [40, 34, 32, 31, 6], we identify three deficiencies that hinder documentation’s utility as a tuning oracle. To ground our analysis, we select a widely deployed relational database system, i.e., PostgreSQL, as a representative running example. PostgreSQL offers a mature documentation ecosystem and has served as the primary benchmark for recent documentation-driven tuning frameworks [26, 17]. • Staleness: Documentation lags behind system evolution. PostgreSQL’s random_page_cost still recommends 4.0 since version 7.4, calibrated for rotational HDD, yet the optimal value on SSDs is closer to 1.1 [41, 39]. • Context insensitivity: Documentation specifies what a parameter does but not when a given value is optimal. PostgreSQL recommends shared_buffers = 25% RAM with no distinction between OLTP and OLAP, SSD and HDD, or read- vs. write-heavy workloads [42, 12, 28]. • Correlation absence: Documentation overlooks parameter correlation. Our analysis shows that the shared_buffers × work_mem correlation explains 39% of performance variance, a dependency entirely absent from the official documentation. Insight: process (how), rather than results (what). The deficiencies above share a common root cause. Documentation records the results of expert tuning, the recommended values that practitioners have concluded through experience, rather than the process by which experts arrive at those recommendations. A result (e.g., “set shared_buffers to 25% of RAM”) is an environmentspecific snapshot. It embeds implicit assumptions about hardware, workload, and system version at the time of writing. When any of those assumptions shift, a new server is provisioned, a workload evolves, a version upgrade changes internal behavior, the recommendation becomes stale or misleading. A process (e.g., “measure buffer hit ratio under representative load; adjust shared_buffers across candidate values") is environment-agnostic. It is a reproducible methodology that seeks the best answer for the target environment and workload it is applied to. The process does not become stale when the system version changes. This distinction has a practical implication for automated tuning. In any deployment scenario, active profiling of the target system under a representative workload is necessary to determine the true 2

optimal configuration. Documentation should serve to accelerate profiling: telling the tuning agent what to measure, how to structure its probes, and what decision rules to apply to the signals it observes. Documentation that only provides static recommended values offers none of this guidance; it either leads the agent to blindly apply stale recommendations or reduces it to uninformed random search over the huge configuration space. Proposal. We present P ERF E VOLVE, a tool that operationalizes expert tuning methodology as executable procedural knowledge. Rather than encoding tuning expertise as value or range recommendations, P ERF E VOLVE encodes it as structured procedural knowledge that an LLM-based tuning agent can learn and execute against a live system to determine the optimal configuration for that specific deployment. P ERF E VOLVE accelerates profiling through two novel techniques: • Dimensionality reduction via sensitivity analysis: From hundreds of parameters, P ERF E VOLVE identifies the small subset that materially affects performance for the given workload via top-k sensitivity analysis. Focusing profiling effort on this subset reduces the effective search space by orders of magnitude and concentrates optimization budget on the parameters where it yields the greatest reward. • Topology discovery for joint optimization: Before committing to any configuration, P ERF E VOLVE mines the correlation structure among sensitive parameters and groups strongly correlated ones into joint optimization components. Parameters within a component are tuned together, capturing correlation effects that per-parameter tuning would miss. We compare P ERF E VOLVE against two state-of-the-art systems, GPTuner [26] and E2ETune [17]. P ERF E VOLVE improves PostgreSQL performance by up to 35.2% across OLTP and OLAP workloads in just 30 trials. Under cross-hardware transfer, prior approaches degrade substantially, while P ER F E VOLVE effectively recovers from these degradations by up to 58.9% without requiring hardwarespecific retuning. Moreover, PERFEVOLVE eliminates invalid or harmful configurations, raising the success rate of tuning experiments from 68% to 100% and further accelerating convergence. Contributions. We make the following contributions: • We systematically identify three fundamental deficiencies that hinder existing system documentation from serving as an effective and actionable tuning oracle. • We propose a methodology that encodes "procedural knowledge" into system documentation, transforming static recommendations (what to set) into reproducible workflows (how to determine what to set). • We design and implement P ERF E VOLVE, a tool that automates the generation of process-oriented tuning documentation. P ERF E VOLVE provides structured skills that empower LLM-based agents to conduct autonomous profiling. • P ERF E VOLVE significantly improves the system performance over state-of-the-art tuning systems.

2

Characterization of Documentation Gaps

2.1

Documentation Deficiencies Across Systems

We survey the official documentation of four widely-deployed systems, including Linux [31], PostgreSQL [40], MySQL [34], and Apache Kafka [6], and identify three types of recurring structural deficiencies. Table 1 summarizes representative examples; we elaborate on each deficiency below. Staleness. Documentation often encodes tuning recommendations as constants calibrated to the hardware and operating systems of their time. Yet modern systems evolve continuously, from CPU and GPU architectures to high-performance NVMe storage and RDMA networking, causing these defaults to silently become stale. For example, in Linux memory management, vm.swappiness = 60 predates modern reclamation techniques (e.g., multi-gen LRU) and modern swap (e.g., Zram). vm.dirty_ratio=20% was calibrated for HDDs; on modern SSDs it delays writeback excessively, producing bursty I/O. Similarly, our experiments show that on SSD-backed VMs, lowering random_page_cost to 1.0 improves write-heavy OLTP throughput by 1.4×, yet degrades readheavy OLTP by 24% 1, because the optimal value is workload-dependent and non-monotonic (§2.2). 3

Table 1: General deficiencies in systems tuning documentation. Each entry contrasts what official documentation provides with what is missing for effective tuning, and summarizes empirically observed consequences (when available). What documentation What is missing Observed impact provides Staleness (outdated operational assumptions) Default (20%) Lack of updated guidance High values delay writeback, causing designed for older Linux vm.dirty_ratio for modern SSD flush bursty I/O and latency spikes under storage with higher behavior. write-heavy DB workloads. write latency. Default value (60) Lack of reflecting modern Suboptimal memory balance under with general guidance memory reclamation (e.g., Linux vm.swappiness modern workloads; may degrade on swap Multi-Gen LRU) and performance under memory pressure. aggressiveness. modern swap (e.g., Zram). On SSD-backed workloads, optimal Default value (4.0) No hardware-aware values depend on workload type: PostgreSQL with qualitative recalibration methodology lowering to 1.0 improves write-heavy random_page_cost guidance assuming for modern SSD/NVMe OLTP by 1.4× but degrades read-heavy HDD-era storage. deployments. OLTP by 24%. No guidance for dynamic Misestimation leads to suboptimal plan PostgreSQL Default value (4GB) environments where cache selection (e.g., index scans avoided effective_cache_size availability fluctuates. unnecessarily). Context Insensitivity (generic defaults without workload conditioning) Heuristic recommends No adaptation for Optimal values vary across workloads; 25% of RAM as a PostgreSQL workload type (OLTP vs misconfiguration leads to 5–16% reasonable starting shared_buffers OLAP), storage medium, throughput degradation on SSD-heavy point on a dedicated and read/write ratio. write workloads. server. MySQL No consideration of May trigger memory contention under Only description of innodb_buffer_pool_ co-located services and co-tenancy, potentially leading to OOM the legality size memory contention. events and unstable performance. Lack of consideration of Suggested based on Misalignment leads to limited scalability partitioning numbers, Kafka num.partitions expected throughput and suboptimal throughput due to load consumer parallelism, and or consumer count. imbalance. workload skew. Correlation Absence (missing multi-parameter modeling) PostgreSQL Parameters are Our ANOVA shows that tuning No correlation-aware shared_buffers × documented largely parameters independently led to guidance on joint tuning. work_mem independently. measurable throughput degradation. Both parameters No explicit coupling High connection counts amplify PostgreSQL work_mem × documented constraint on total memory per-query memory usage, causing OOM max_connections separately. consumption. or instability. Separate guidelines Throughput plateaus when partitioning Kafka partitions × No cross-component for partition count and is misaligned with consumer consumers coordination strategy. consumer threads. parallelism. System Parameter

In all cases, documentation defaults are written once and rarely revisited, while systems (both hardware and software) keep updating. Context insensitivity. Documentation typically provides default values or ranges without conditioning on workload characteristics or deployment context. Yet configuration impact is inherently context-dependent: the same value can be optimal in one setting and harmful in another. Consider PostgreSQL’s canonical recommendation of shared_buffers = 25% of RAM, this single figure elides workload type, storage medium, and read/write ratio. In practice, misconfiguration along this single parameter alone leads to 5–16% throughput loss (§2.2). Similar issues appear in MySQL (innodb_buffer_pool_size, ignoring co-tenancy and competing memory pressure) and Kafka (num.partitions, ignoring coordination with consumers), leading to instability or suboptimal throughput. The root cause is that it is impossible for system developers to enumerate the combinatorial space of workloads, deployment environments at documentation time. Correlation absence. In most cases, documentation describes parameters in isolation, implicitly assuming independent tuning. However, parameter correlations are both common and often dominant. Our experiments (§2.2) show that 60% of parameter pairs exhibit interaction strength >15%. In 4

particular, the interaction between shared_buffers and work_mem explains 39% of performance variance, measured by the ANOVA effect size η 2 (i.e., the fraction of total variance attributable to the correlation term). Critically, many strong correlations span subsystems (e.g., memory × concurrency), yet remain undocumented. 2.2

Case Study: PostgreSQL with 300+ Parameters

We select PostgreSQL as our case study for three reasons. First, it exposes 300+ tunable parameters spanning I/O, memory, concurrency, query planning, etc. Second, it has a mature documentation ecosystem with extensive best-practice guidelines from practitioners. Third, it is the target of various documentation-driven tuning approaches [26, 17, 53], making it the ideal system for evaluating documentation quality. We deploy PostgreSQL v16 instances on 150 virtual machines with identical hardware configurations (8 vCPU, 8 GB DRAM, 200 GB SSD). We evaluate three representative workloads: TPC-C-r (readheavy OLTP), TPC-C-w (write-heavy OLTP), and TPC-H (analytical OLAP). All results report performance change relative to the default PostgreSQL configuration; each data point is averaged over three independent runs. Finding-#1: Established best practices may become obsolete. We measure two widely-used baselines: PostgreSQL official guidelines (PG-Official) and PGTune [39], which translates documentation into heuristic, resource-aware rules but lacks workload adaptivity and correlation awareness.

PG-Official

Q1 Q2

PGTune +27%

+16% +14%

+4%

+16% +18% +21% +22% +17% +20%

Q3 Q4 Q7 +12%

Q12 Q16 0

5

10

15

+17% +19%

20

+26%

25

Latency increase vs. default (%)

30

Figure 1: Latency increase on TPC-H when applying PG-Official and PGTune rules (7 of 22 queries degraded by >10%). Both rule sets lead to worse latency on the same kinds of sort- and aggregationintensive queries. Figure 1 drills into TPC-H’s 22 queries and pinpoints 7 out of them that both rule sets degrade by more than 10%. The affected queries share a common trait: they are sort- or aggregation-intensive (e.g., Q1 performs a full-table aggregation with sorting; Q7 joins multiple tables with an orderby clause). The root cause is a memory allocation mismatch. Both PG-Official and PGTune set shared_buffers = 2 GB (the canonical “25% of RAM” rule), which shrinks the OS page cache available for temporary files, while leaving work_mem at its 4 MB default, which is too small for the large intermediate results these queries produce. As a result, sort and hash operations spill to disk, inflating latency by 12–27%. A second example reinforces the pattern. Both rule sets recommend checkpoint_completion_target = 0.9 (“spread checkpoint writes over 90% of the interval”), advice calibrated for rotational disks where I/O bursts are expensive. On our SSD-backed VMs, this recommendation hurts: a single-parameter sweep across 6,297 configurations shows that the default value (0.5) outperforms 0.9 by 15% on read-heavy OLTP, and the optimal value (0.0, i.e., checkpoint as fast as possible) outperforms 0.9 by 24% on write-heavy OLTP. 5

Performance improvement vs. default (%)

These failures share a common cause: documentation records conclusions derived under specific assumptions, but provides no mechanism to detect when those assumptions are violated.

60

+35.2%

Independent (per-param, then combine) Joint (2D search over sb × cct)

40 20 48.6%

+1.5%

0 -4.3%

20

-16.1%-18.6%

-13.4%

TPC-C-r (optimized for)

TPC-C-w (cross-apply)

TPC-H (cross-apply)

Figure 2: Independent vs. joint optimization for shared_buffers (sb) × checkpoint_completion_target (cct) across three workloads. “Independent” tunes each parameter to its individually-optimal value in isolation, then combines the individually optimal values. “Joint” searches the two-dimensional space together. Finding-#2: Optimal configurations are workload-dependent. System documentation typically provides generic, one-size-fits-all recommendations. In practice, however, the effectiveness of a configuration is heavily conditioned on workload characteristics, including read/write ratio, access patterns, and resource bottlenecks. Our study shows that most documentation typically specifies a single heuristic or default value per parameter. For example, shared_buffers is commonly recommended as a fixed fraction of memory (e.g., 25%), and checkpoint-related parameters such as checkpoint_completion_target are described in terms of general trade-offs (e.g., smoothing I/O). These recommendations are presented as broadly applicable starting points. Such descriptions do not capture how parameter choices should adapt to workload-specific conditions. They lack guidance on when a configuration that benefits one workload (e.g., read-heavy OLTP) should be adjusted or even reversed for another (e.g., write-heavy OLTP or OLAP). In particular, documentation does not specify how changing bottlenecks (buffer reuse vs. logging vs. large scans) alter the role of each parameter. We observe that configurations optimized for one workload often fail to transfer. As shown in Figure 2, a configuration that improves throughput by +35.2% on TPC-C-r degrades performance by −4.3% on TPC-C-w and by up to −18.6% on TPC-H. Even configurations obtained from careful perparameter tuning exhibit similar issues when applied across workloads. Overall, the performance gap between workload-specific optima can reach up to 48.6%, indicating that misaligned configurations can significantly harm system performance. These results highlight a fundamental limitation: there is no universally optimal configuration. Effective tuning requires workload-aware adaptation, yet existing documentation cannot indicate when or how configurations should change. Finding-#3: Parameter correlations are pervasive and can be cross-subsystem. To determine which parameters should be jointly tuned, we quantify pairwise correlations using the two-stage
methodology in §3.2. We select 11 high-sensitivity parameters and exhaustively test all 11 2 = 55 pairs via 2 × 2 factorial experiments (n = 1) on TPC-C-r. Table 2 ranks the strongest correlation. Figure 3 shows that 33 of 55 pairs (60%) exceed the 15% correlation threshold, indicating that parameter correlations are the norm rather than exceptions. The strongest pair, commit_delay × 6

Parameter interaction strength (%) for 55 parameter pairs on tpcc-r 96 96

49

43

2

41

1

10

74

12

31

8

1

81

0

23

51

2

44

51

94

54

7

39

42

1

42

43

53

56

9

24

13

0

18

62

20

34

1

42

14

0

51

12

0

26

42

3

67

20

43

56

41

11

0

49

8

43

1

94

2

81

54

53

41

0

7

56

62

1

23

39

9

20

0

10

51

42

24

34

51

42

74

2

1

13

1

12

3

43

12

44

42

0

42

0

67

56

11

31

51

43

18

14

26

20

41

0

100

80

60

40

20

5 5

0

co m de mit lay cp u_ co op bg st w mu_lru de lt fau cp stats lt u_ tu co ple pa va st ge cu _d um fro irty m lim_col m it wo ax_p rke ar pa ranrs ge do _c m os v pa acut ge um _h i de logit c_ ca wm l

commit delay cpu_op cost bgw_lru mult default stats cpu_tuple cost vacuum page_dirty from_col limit max_par workers random page_cost vacuum page_hit logical dec_wm

Figure 3: Interaction strength for 55 parameter pairs on TPC-C-r. Each cell shows the interaction percentage; cells above 15% (bold) indicate candidate correlations for fine-grained verification. 33 of 55 pairs (60%) exceed the threshold. Table 2: Top-10 parameter interactions. “Int.%” is the interaction strength. 8 of 10 span different PostgreSQL subsystems. Param. A

Param. B

commit_delay bgw_lru_mult cpu_op_cost commit_delay from_col_limit cpu_tuple_cost max_par_workers default_stats bgw_lru_mult cpu_tuple_cost

cpu_op_cost default_stats cpu_tuple_cost random_page_cost vac_page_hit vac_page_dirty vac_page_hit vac_page_dirty cpu_tuple_cost default_stats

Int.%

Cross?

96.0 93.7 80.9 73.6 66.8 62.0 56.0 55.5 53.5 52.6

✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗

cpu_operator_cost, reaches 96% interaction strength (Int.%), measured as the fraction of performance variance, indicating that the effect of one parameter largely depends on the other. Moreover, correlations are frequently cross-subsystem: 8 of the top-10 pairs span different PostgreSQL components (e.g., WAL × planner, background writer × query optimizer), yet such relationships are absent from documentation. Summary. These three findings share a common root cause: documentation encodes what to set, but not how to determine what to set. Today’s documentation tuning recommendations are tied to specific hardware (staleness), blind to workload context (insensitivity), and isolated per parameter (independence). This motivates us to seek a better form of knowledge that encodes the process of tuning, instead of the results. 7

3

P ERF E VOLVE Design

At a high level, P ERF E VOLVE is a tool that serves as an automated engine which synthesizes procedural tuning documents from a comprehensive profiling process. P ERF E VOLVE’s “step-bystep” design philosophy allows it to leverage the reasoning capabilities of modern LLM-based agents [27, 54, 52, 43, 16, 35], thereby accelerating the profiling process on diverse deployment environments. Specifically, P ERF E VOLVE introduces two novel techniques: dimensionality reduction and topology discovery, which together make profiling practical at scale. Dimensionality reduction identifies the small subset of parameters that materially affect performance; topology discovery reveals which of those parameters are correlated and must therefore be co-optimized.

Traditional Method Generate

Provide Knowledge

Limited knowledge, potential errors, outdated information

Origin Documents Knowledge Base

PerfEvolve Method

Optimize

AI Model

Poor Optimization, Slow Convergence!

Offline Profiling Config

Config Group Sensitivity scan Performance data

Config Space

Interaction screen Joint optimization Group performance data Space performance data

Online Deployment

Generate

Knowledge Base

Provide Knowledge

Optimize

AI Model

Excellent Optimization, Fast Convergence!

Figure 4: P ERF E VOLVE architecture. The offline profiling phase runs once per system version: it applies dimensionality reduction and topology discovery to produce a procedural tuning document. The online deployment phase runs per deployment: an LLM agent executes the document’s skills, performing targeted profiling guided by the offline-derived reference data. Goals. P ERF E VOLVE is designed around three objectives: • Executable: The documentation should define concrete actions (e.g., “run benchmark B with configuration C”, “compute η 2 from results”) and explicit decision rules, enabling reproducible step-by-step execution by an agent (either human-based or LLM-based) without ambiguity. • Verifiable: Post-conditions (predicates expected to hold after execution) and procedural knowledge (relationship from offline profiling to support decisions) should support self-checking at each step. For example, if ≤ 5 sensitive parameters are found (violating “|top-k | ≥ 5”), the agent detects the anomaly and triggers an adaptation skill. • Transferable: Procedures and decision rules are environment-agnostic. Adapting to a new version requires updating calibration data, not rewriting the document. Workflow. P ERF E VOLVE’s workflow consists of two phases: an offline phase (run once per software version), and an online phase (run per deployment). During the offline profiling phase, given a target system with n tunable parameters and W representative workloads, P ERF E VOLVE executes the two techniques in sequence: 8

• Dimensionality reduction: scan all n parameters to identify the k ≪ n that significantly affect performance, along with their safe operating ranges and response-curve shapes.
• Topology discovery: screen all k2 parameter pairs for correlation, construct a graph, and decompose it into connected components. The outputs are fed into a document generator that produces a set of executable skills (§3.3). During the online deployment phase, an LLM-based tuning agent receives the procedural document and executes its skills against the target deployment. The document tells the agent what to measure and how to interpret the results; the agent performs only the targeted experiments prescribed by each skill. Because the offline phase has already identified which parameters matter (via dimensionality reduction) and which must be co-optimized (via topology discovery), the online phase converges in tens of experiments rather than thousands. Figure 4 illustrates the two-phase architecture.

3.1

Dimensionality Reduction

Problem statement. A complex system may expose hundreds of tunable parameters, yet exhaustive exploration of all of them is intractable [20, 51]. Worse, existing documentation provides no principled guidance on which parameters have meaningful performance impact, leaving practitioners to tune blindly. Top-k sensitivity analysis. We perform a single-parameter sweep for each of the n parameters: for parameter xi , we fix all others at their defaults and evaluate Li ∈ {3, . . . , 9} values spread across the documented or empirically safe range. Each configuration is benchmarked with r = 3 repetitions under each of the W workloads. For each parameter xi and workload w, we compute the coefficient of variation [38]:

CVi,w =

maxv TPS(xi =v, w) − minv TPS(xi =v, w) TPS(xi =default, w)

(1)

where TPS denotes the mean over repetitions. We define the aggregate sensitivity as CVi = maxw CVi,w , and select Pn the top-k parameters exceeding a threshold τs (5% by default). The total sweep requires i=1 Li × r × W experiments. For PostgreSQL’s 116 performance-relevant parameters, this amounts to 116 × L̄ × 3 × 3 ≈ 6,297 benchmark runs. Because each parameter’s sweep is independent of all others, this phase is embarrassingly parallel: on our 150-server cluster, it completes within one day. Takeaway. Dimensionality reduction produces 4 artifacts in the procedural document: • Sensitivity ranking: parameters ordered by CVi . In our study, only 15 of 116 parameters exceed the 5% threshold; the remaining ∼100 have CV < 1% and can safely remain at their defaults. • Safe ranges: for each top-k parameter, the empirically observed range [minv , maxv ] within which no crash or severe degradation (>50% throughput loss) occurred. These ranges eliminate the unsafe configurations responsible for the 32% crash rate observed in GPTuner. • Response-curve shapes: each parameter is classified as monotonic-up, monotonic-down, nonmonotonic (interior optimum), or step-function (threshold effect). This classification directly informs the agent’s search strategy: monotonic parameters require only boundary evaluation, whereas non-monotonic ones require finer sweeps around the peak. • Per-workload sensitivity: different workloads may induce different top-k sets [28]. Recording workload-specific rankings allows the agent to adapt its focus when the deployment workload diverges from the offline representative. Figure 5 shows the resulting sensitivity distribution. The long-tail structure, a handful of high-impact parameters and a large mass of negligible ones, is precisely the property that makes dimensionality reduction effective. By narrowing the search space from n = 116 to k = 15, we achieve a one-orderof-magnitude reduction in the parameters that downstream optimization must explore. 9

Sensitivity (impact %)

200

Top-15 (>95% of variance)

5% threshold Top-15 cutoff

150 100

~100 parameters: CV < 1%, safe to ignore

50 0

0

20

40

60

80

Parameter rank (sorted by sensitivity)

100

120

Figure 5: Sensitivity (CV) of all 116 PostgreSQL performance-relevant parameters sorted in descending order, on the TPC-C-r workload. The distribution exhibits a pronounced long tail: the top 15 parameters account for >95% of cumulative performance variation. The dashed line marks the 5% threshold τs . 3.2

Correlation Topology Discovery

Problem statement. Reducing to k parameters is necessary but not sufficient: if parameters have implicit correlation, tuning them independently can be actively harmful. Existing documentation has little knowledge on parameter correlations, leaving optimizers to assume independence by default. We aim to discover the topology, determining which parameters must be jointly optimized and which can safely be treated in isolation.
Two-stage factorial analysis of variance (ANOVA) [11]. We screen all k2 parameter pairs through a two-stage process designed to balance statistical rigor with experimental cost. Stage A: Coarse screening. For each pair (xi , xj ), we run a 2×2 factorial experiment (4 configurations, 1 repetition per workload), using the extreme values from the sensitivity scan as the two factor levels. We compute an approximate interaction percentage: Int%ij =

|y ++ − y +− − y −+ + y −− | |y ++ + y +− + y −+ + y −− |/4

(2)

where y ab is the mean TPS at level (a, b). Pairs with Int% > 15% advance to Stage B; pairs below 5% are marked independent. This threshold is intentionally liberal: the 2 × 2 design with n = 1 overestimates interaction strength by approximately 2× (validated experimentally), so Stage A maximizes recall at the cost of some false positives. Stage B: Fine screening. For each pair passing Stage A, we run a 4 × 4 factorial design with r = 3 repetitions per cell (48 runs per pair per workload) and measure interaction strength using effect size (partial η 2 ) following standard ANOVA practice [25]. We report the partial effect size: SSij 2 ηij = (3) SStotal which captures the proportion of variance explained by the correlation term. We apply BenjaminiHochberg FDR correction [7] across all tested pairs and retain those with η 2 > 0.15 and corrected p < 0.05 as confirmed correlations. Building correlation graphs. We construct a weighted undirected graph G = (V, E) where V is 2 the set of k sensitive parameters and each edge (i, j) ∈ E carries weight ηij for every confirmed correlation. We then decompose G into connected components {C1 , C2 , . . . , Cm }. Parameters within the same component must be jointly optimized; parameters in different components or isolated nodes can be tuned independently without loss of optimality. Takeaway. Interestingly, we observe a structural sparsity property that makes component-wise optimization computationally tractable in practice. Although 64% of PostgreSQL parameter pairs 10

Cost Estimation

Edge weight

I/O Scheduling

2 = 0.9

Memory / I/O

max_parallel_workers

work_mem

0.4 0.1

cpu_operator_cost vacuum_cost_page_hit

Query Planner random_page_cost

cpu_tuple_cost

vacuum_cost_page_dirty

bgwriter_lru_multiplier

logical_decoding_work_mem

effective_cache_size

default_statistics_target

WAL / Commit

commit_delay

shared_buffers

effective_io_concurrency

from_collapse_limit

checkpoint_completion_target

Figure 6: Correlation graph for PostgreSQL on the TPC-C-r workload. Left: nodes are the top15 parameters; edges indicate confirmed correlations (η 2 > 0.15, p < 0.05); edge thickness is proportional to η 2 ; colors denote connected components. Right: the resulting optimization strategy. Component C1 (shared_buffers, work_mem, checkpoint_completion_target) requires a 3dimensional joint search; C2 requires 2-dimensional; isolated nodes are tuned independently.

exhibit statistically significant correlation, the graph decomposes into low-dimensional components. Specifically, the largest component contains only 3–4 parameters. This decomposition reduces the search space from an intractable 415 global configurations to a series of manageable sub-problems (e.g., 43 × 3 = 192 runs for a 3-parameter component), making exhaustive local optimization feasible.

3.3

Procedural Document Generation

We formalize a procedural tuning document as a directed acyclic graph (DAG) of skills, where each skill is a self-contained executable tuning unit. Specifically, a skill is a tuple of the following elements: • preconditions: predicates required before execution (e.g., “baseline measurement must be completed”); • procedure: an ordered sequence of actions (benchmark, measure, compare) with conditional branches; • decision criteria: rules selecting execution paths based on signals (e.g., “if η 2 > 0.15, trigger joint optimization”); • postconditions: predicates expected after execution (e.g., “optimal configuration identified with >95% confidence”). • reference data: empirical data from offline profiling that anchor the decision criteria (e.g., sensitivity thresholds). The outputs of dimensionality reduction (§3.1) and topology discovery (§3.2) are compiled into an executable procedural document structured as a DAG of skills. The generator produces three types of skills: • Per-parameter skills: For each parameter in the top-k set: a sensitivity profile (i.e, CV, response shape, safe range, workload-specific ranking) and a verification step that checks whether the documented behavior holds on the target system. • Per-component skills: For each connected component in the correlation graph: a joint optimization skill specifying the search space and decision criteria for adopting joint vs. independent tuning. • Orchestration skill: A root-level skill that orchestrates the full tuning workflow, including diagnosis, sensitivity scanning, correlation checking, joint optimization, and cross-workload verification, with each transition governed by explicit decision criteria. For PostgreSQL v16, the generated document contains 23 skills and 160 parameter profiles in total. 11

3.4

Putting It All Together

P ERF E VOLVE operates in one of the following two modes. Mode 1: Full procedural execution. The LLM-based tuning agent receives the complete skill DAG as part of its system prompt. At each skill, it interprets the procedure, invokes benchmarks via a system API, evaluates decision criteria against the observed results, and transitions to the next skill. This mode realizes the full “step-by-step” paradigm: the agent performs deployment-specific profiling guided by the offline-derived experience, and converges without any pre-baked configuration recommendations. Mode 2: Knowledge injection into existing frameworks. For compatibility with existing tuning systems, P ERF E VOLVE exports a subset of its procedural knowledge in a format compatible with the target framework. For GPTuner [26], we export per-parameter JSON containing: (1) the top-k parameter list (replacing GPTuner’s LLM-extracted 57-parameter list); (2) empirical safe ranges (replacing the documentation-derived ranges that cause 32% crash rates); and (3) correlation annotations as advisory hints for the optimizer. This mode demonstrates that P ERF E VOLVE’s knowledge is not tied to any particular agent architecture: it can improve any tuning system that accepts structured knowledge as input.

4

Evaluation

We evaluate P ERF E VOLVE to answer four research questions: • RQ1: Does P ERF E VOLVE achieve better database performance than state-of-the-art approaches? (§4.1) • RQ2: How does procedural knowledge outperform declarative knowledge? (§4.2) • RQ3: What is the offline profiling cost? • RQ4: What do key techniques, dimensionality reduction and topology discovery, contribute to P ERF E VOLVE? (§4.4) Experimental setup. We use two hardware configurations: • Virtual machine cluster (primary): 150 PostgreSQL 16 instances (2 vCPU, 8 GB RAM, SSD). P ERF E VOLVE’s offline profiling was conducted on this cluster, so it serves as the matched evaluation environment where profiling conditions equal deployment conditions. • High-end server: 192-core Xeon 8575C, 1 TB RAM, 8×H100 GPUs (for ML inference used by E2ETune [17]). Used to evaluate cross-hardware transfer and end-to-end comparison at scale. Baselines. Table 3 summarizes all methods. We compare against two state-of-the-art LLM-based tuning systems: GPTuner [26] extracts parameter constraints from documentation via LLM and feeds them into a SMAC Bayesian optimizer [18] (57 parameters, 30–100 iterative trials); E2ETune [17] fine-tunes Mistral-7B on historical tuning data and generates a complete configuration in one inference (44 parameters). The two differ in every dimension, iterative vs. one-shot, explicit extraction vs. implicit learning, making them complementary tests of P ERF E VOLVE’s generality. For each, we evaluate both the original and a P ERF E VOLVE-enhanced variant (knowledge injected as SMAC constraints or prompt augmentation, with zero algorithm changes). We also include static baselines (PG-Official and PGTune [39]). Workloads. We employ three representative benchmarks via BenchBase [13]: TPC-C-r (OLTP readheavy, SF=50, 16 terminals, 80% OrderStatus), TPC-C-w (OLTP write-heavy, SF=20, 16 terminals, 45% NewOrder + 43% Payment), TPC-H (OLAP, SF=1, 22 queries serial). Each configuration is benchmarked with 3 repetitions. 4.1

End-to-End Performance

Table 4 reports end-to-end results on two testbeds: (1) the VM cluster, where profiling conditions match deployment, and (2) the server, where profiling knowledge is transferred. 12

Table 3: Method comparison. P ERF E VOLVE knowledge is injected into GPTuner (as SMAC parameter space) and E2ETune (as prompt augmentation) without changing their algorithms. Method

Type

# Parameters

PG-Official / PGTune GPTuner [26] GPTuner+P ERF E VOLVE E2ETune [17] E2ETune+P ERF E VOLVE

Static rules LLM + Bayesian opt. LLM + Bayesian opt. LLM one-shot LLM one-shot + prompt

∼100 57 15 44 44

Table 4: End-to-end performance improvement (%) over default PostgreSQL. Cluster results are from the VM testbed where P ERF E VOLVE’s profiling was conducted (profiling = deployment environment; GPTuner: 100 trials). Server results are from server (cross-hardware transfer; GPTuner: 100 trials, E2ETune: 1 inference). Bold: best per workload per testbed. Cluster (2 vCPU, 8 GB) System Knowledge GPTuner (LLM & BO

Original (PG docs) +P ERF E VOLVE knowledge Gain

E2ETune Original (PG docs) (LLM +P ERF E VOLVE one-shot knowledge inference)Gain

Server (192-core, 1 TB)

TPC-C-r

TPC-C-w

TPC-H

TPC-C-r

TPC-C-w

TPC-H

+9.0 68% valid +10.4

+16.5 70% valid +19.7

−3.2 81% valid +2.9

−54.2

−56.4

−54.7

−3.3

−10.6

+4.2

100% valid +1.4

100% valid +3.2

100% valid +6.1

+50.9

+45.8

+58.9

−1.0 +1.0

+0.7 +0.0

+0.0 +0.5

+6.9 +8.4

+12.0 +12.7

+33.6 +35.2

+2.0

−0.7

+0.5

+1.5

+0.7

+1.6

Matched environment (VM cluster). In this setting, all methods run on hardware consistent with the profiling environment. Three patterns emerge from the VM results. First, traditional documentation rules hurt analytical workloads. PG-Official degrades TPC-H by 54.7%, confirming the staleness finding from §2.2. Second, P ERF E VOLVE eliminates invalid configurations. GPTuner-Original wastes 19–32% of its 100-trial budget on crashed or severely degraded configurations, while GPTuner+P ERF E VOLVE achieves 100% valid trial rate across all workloads. The throughput improvement on TPC-C-w (+19.7%) is mainly attributable to knowledge quality, where the algorithm and budget are identical. Third, P ERF E VOLVE Agent, which executes the full procedural document (sensitivity scan → correlation detection → joint optimization), achieves the largest gains by discovering workload-specific configurations through systematic profiling. Cross-hardware transfer (server). We test whether P ERF E VOLVE knowledge profiled on 8 GB VMs generalizes to a 192-core, 1 TB server, a 96× core-count and 128× memory gap. Even across a 96× hardware gap, P ERF E VOLVE knowledge rescues GPTuner from catastrophic failure. GPTuner-Original, which consumes raw PG documentation via LLM extraction, halves throughput on TPC-C-r (−54.2%) and more than doubles latency on TPC-H (−54.7%). Replacing the knowledge source with P ERF E VOLVE’s procedural document, 15 sensitivity-ranked parameters with empirical safe ranges, transforms GPTuner from catastrophic to near-default, with zero changes to its SMAC optimizer. For E2ETune, which already embeds implicit PostgreSQL knowledge through training, P ERF EVOLVE ’s explicit procedural knowledge provides complementary gains (+1.5% on TPC-C-r, +1.6% on TPC-H), confirming that the two knowledge forms are not redundant. Limitations on TPC-C-w. P ERF E VOLVE knowledge does not improve TPC-C-w on server (GPTuner+P ERF E VOLVE: −10.6%). The 1 TB server has fundamentally different memory pressure for write-heavy workloads than the 8 GB VMs where profiling was conducted. This underscores that 13

P ERF E VOLVE’s reference data (safe ranges, interaction strengths) is hardware-specific, while the procedural methodology (sensitivity scan → correlation screen → joint optimize) remains valid. On the VM cluster, where profiling matches deployment, this limitation does not arise. 4.2

Why Knowledge Form Matters

We inject five knowledge variants into E2ETune, controlling information quantity while varying the knowledge form: whether the LLM receives recommended values (declarative) or structured tuning methodology (procedural). Table 5 reveals several counter-intuitive patterns: Table 5: Knowledge form experiment (server, E2ETune, 5 runs per condition). Performance improvement (%) over default. Declarative knowledge provides specific parameter values; procedural knowledge provides tuning methodology. Even correct values hurt; procedural structure alone helps. Knowledge

Form

TPC-C-r

TPC-C-w

TPC-H

E2ETune Vanilla

None

+6.9

+12.0

+33.6

Declarative (what to set): + Wrong Numbers + Full Numbers + HW-Relative

Incorrect values Correct values Adapted ratios

+0.2 −0.4 +1.0

+1.7 −1.9 −1.4

−8.3 −2.1 +2.2

Procedural (how to determine): + Structure-Only + Full P ERF E VOLVE

Steps, no data Steps + ref. data

+1.3 +8.4

−0.1 +12.7

+5.3 +35.2

• Declarative knowledge usually fails. Even correct specific values (Full Numbers) degrade performance on all three workloads (−0.4% to −1.9%) relative to providing no knowledge at all. The LLM anchors on the injected numbers and reduces its exploration, even when those numbers are suboptimal for the target hardware. Incorrect values (Wrong Numbers) are catastrophic on TPC-H (−8.3%), directly illustrating the staleness problem identified in §2.2. • Procedural structure alone outperforms all declarative forms. Structure-Only provides only the tuning steps (“sweep the parameter; record the response curve; check for correlations”) with no specific data, which already outperforms the best declarative variant on TPC-H (+5.3% vs. +2.2%). The process carries value independent of specific calibration data. • Full P ERF E VOLVE combines structure with data for the best results. Full P ERF E VOLVE (procedural steps + empirical reference data) achieves the highest improvement across all workloads. The reference data accelerates convergence, telling the agent where to look, but the procedural structure is the essential ingredient that enables correct reasoning about the parameter space. The above results validate our key point: documentation should encode how to determine the right configuration, rather than what the right configuration is. 4.3

Profiling Cost Analysis

Table 6: Cost breakdown. The offline phase runs once per system version; the online phase runs per deployment. Phase

Runs

%

Parallelism

Offline (one-time): 1. Sensitivity scan 2. Correlation screen 3. Joint optimization Total

6,297 ∼3,500 ∼1,200 ∼11,000

57 32 11

Fully parallel Per-pair parallel Per-component parallel

Online (per deployment): Agent-guided tuning

30–120

Sequential

14

TPS improvement (%)

40

+35.2%

Stage 3: Joint optimization (final config)

30 Stage 2: Interaction screen (topology graph)

20

Stage 1: Sensitivity scan (top-k + safe ranges)

10 0

+12.4% +5.0%

0% 0

20

40

60

Offline profiling budget (%)

80

100

Figure 7: Profiling cost vs. tuning quality. Each stage completion triggers a discrete jump in performance.

Offline profiling (∼11,000 runs) decomposes into three stages, each for a distinct capability (Table 6). Figure 7 shows a clear staircase pattern: performance improves only at stage boundaries, as each stage produces a qualitatively new artifact (parameter ranking, correlation topology, or joint configuration). • Discrete returns. Profiling exhibits stage-level gains: Stage 1 yields +5% via dimensionality reduction and safe ranges; Stage 2 improves to +12.4% by exposing correlation structure; Stage 3 reaches +35.2% through joint optimization. Partial completion within a stage provides little benefit, as incomplete artifacts (e.g., partial correlation graphs) cannot guide optimization reliably. • High return under partial investment. Even Stage 1 alone (57% of budget) delivers +5% by reducing the search space (116 → 15 parameters) and eliminating unsafe configurations that waste trials. • Disproportionate payoff of joint optimization. Stage 3 consumes only 11% of the budget but yields the largest gain (+22.8%). This is enabled by topology-aware decomposition from Stage 2, which reduces the search to small interacting groups. 4.4

Ablation: Contribution of Each Technique

We inject five variants of P ERF E VOLVE knowledge into E2ETune on the high-end server (3 repetitions per condition) to isolate the contribution of each component. Table 7: Knowledge component ablation (high-end server, E2ETune, 3 repetitions, live BenchBase). Performance improvement (%) over default. Best per workload in bold. Condition

TPC-C-r (%)

TPC-C-w (%)

TPC-H (%)

E2ETune Vanilla

+6.9

+12.0

+33.6

+ Ranking only + Interaction only + Safe range only + Full (P ERF E VOLVE)

+9.5 +3.3 +7.9 +8.4

+9.0 +13.2 +12.6 +12.7

+30.9 +30.1 +32.8 +35.2

Table 7 shows that each component’s contribution is workload-dependent: Ranking dominates on read-heavy OLTP (TPC-C-r: +9.5%), because read-heavy workloads are governed by a few memory/I/O parameters that ranking correctly identifies. Correlation knowledge dominates on write-heavy OLTP (TPC-C-w: +13.2%), because write-heavy workloads involve coupled I/O paths (buffer pool ↔ WAL ↔ checkpoint) where one parameter’s optimal value depends on another. Full knowledge is the most robust: it achieves the best result on TPC-H (+35.2%) and near-best on both OLTP workloads, without requiring the user to know which component matters. 15

To demonstrate the concrete cost of ignoring parameter correlations, we select the shared_buffers × checkpoint_completion_target pair and compare independent and joint optimization on the VM cluster. Tuning each parameter independently to its optimum and combining the results yields a −13.4% throughput change on TPC-C-r; tuning them jointly over the 2D space yields +35.2%. This is because a large buffer pool paired with infrequent checkpoints causes dirty-page accumulation and I/O storms, but each parameter appears optimal in isolation when the other is held at its default. This result is the most direct evidence for topology discovery’s value: the same parameter values produce a 48.6% performance gap depending solely on whether the tuning process accounted for their correlation.

5

Discussion

Generalization beyond databases. Although P ERF E VOLVE is evaluated on PostgreSQL, its methodology is not specific to DBMS. Many systems, such as operating systems, language runtimes, Web servers, and distributed systems, also expose large configuration spaces with workload-dependent and cross-parameter effects. In principle, P ERF E VOLVE can be instantiated for these systems through a similar two-phase workflow: offline profiling discovers sensitivity and interaction structure, while online execution applies the generated skills for deployment-specific tuning. However, different systems have different failure modes and observability constraints; for example, database misconfiguration usually leads to performance degradation, whereas OS-level misconfiguration may cause crashes or service instability. As such, applying P ERF E VOLVE beyond DBMS may require stronger rollback, sandboxing, and safety-aware recovery mechanisms. P ERF E VOLVE can be viewed as a general methodology for constructing executable tuning knowledge. Profiling cost and transferability. P ERF E VOLVE does not eliminate offline profiling overhead. The offline phase requires substantial benchmark execution to construct sensitivity rankings, safe ranges, and correlation graphs; in our PostgreSQL study, this amounts to roughly 11K runs. Since most runs are embarrassingly parallel and performed once per software version, the cost can be amortized across many deployments, making P ERF E VOLVE more suitable for mature, stable software stacks where tuning is revisited periodically than for one-off or rapidly evolving environments. Meanwhile, the workflow itself, including sensitivity scan, interaction screening, and componentwise joint optimization, is more transferable than the empirical reference data. Safe ranges, sensitivity strengths, and interaction weights may still shift with hardware, workload mix, and deployment scale. Therefore, when the target platform differs substantially from the profiling environment, P ERF E VOLVE’s workflow remains applicable, while part of the reference data should be recalibrated. Workload dependence. P ERF E VOLVE assumes that offline profiling workloads are representative of the target deployment. This assumption is necessary because tuning decisions are inherently workload-dependent: a parameter that is important for one workload may be irrelevant or even harmful for another. P ERF E VOLVE partially mitigates this issue by recording per-workload sensitivity profiles and by verifying key decisions during online execution. Nevertheless, it cannot guarantee correctness under arbitrary workload drift. If the online workload activates a previously irrelevant subsystem, or if the workload mix changes substantially over time, the generated skills may focus on an incomplete parameter set. In such cases, workload monitoring and periodic re-profiling are necessary to keep the procedural document aligned with the deployed system. Higher-order parameter interactions. P ERF E VOLVE currently focuses on pairwise and lowdimensional parameter correlations. This design choice is motivated by practicality: exhaustive exploration of high-order interactions is computationally prohibitive, while our empirical results suggest that many important dependencies can already be captured by sparse, low-dimensional correlation components. However, real systems may contain higher-order effects that are not visible from pairwise screening alone. Consequently, P ERF E VOLVE may underestimate dependencies that emerge only when three or more parameters change together. A promising direction is hierarchical interaction discovery, where higher-order candidates are explored only when their lower-order subsets exhibit high sensitivity or strong interaction. Agent reliability. The skill-based design reduces ambiguity for LLM-based tuning agents, but it does not fully solve agent reliability. In full procedural execution, the agent must still invoke 16

benchmarks, parse logs, compare measurements, and apply decision rules correctly. Although the generated skills contain preconditions, postconditions, and reference data for self-checking, they cannot completely prevent agent-side failures such as misinterpreting noisy measurements, prematurely terminating experiments, or incorrectly applying a decision rule. Therefore, P ERF E VOLVE should be understood as a structured control layer that improves the reliability of agentic tuning, not as a complete guarantee of autonomous correctness. Documentation and skills. The goal of P ERF E VOLVE is not to replace traditional documentation. Static documentation remains valuable for explaining parameter semantics, legal value ranges, and operational cautions. The limitation is that such documentation usually records what experts concluded, but not how they reached those conclusions. P ERF E VOLVE complements documentation by turning tuning methodology into executable, verifiable skills. This distinction also clarifies the scope of our contribution: P ERF E VOLVE is not a universal optimizer that guarantees globally optimal configurations. Rather, it provides a knowledge representation that helps agents perform targeted measurement, avoid stale or unsafe recommendations, and account for parameter interactions that static documentation often omits.

6

Related Work

LLM-based system tuning. GPTuner [26] pioneered the use of LLMs to extract structured knowledge from database documentation and feed it to a Bayesian optimizer. D-Bot [58] and DB-GPT [59] extend this direction by applying LLMs to anomaly diagnosis and root-cause analysis. Recent systems such as BYOS [30], OS-R1 [29], and Wayfinder [19] further apply LLMs to operating-system configuration tuning and specialization. While these systems demonstrate the potential of LLMs for system optimization, they largely treat the underlying knowledge source as fixed. P ERF E VOLVE is complementary: rather than merely consuming existing documentation, it encodes empirically grounded procedural knowledge into documentation. The resulting gains transfer across both GPTuner, a BO-based tuner, and E2ETune [17], an LLM-inference-based tuner, confirming that the improvement lies in the upgraded knowledge rather than in a particular tuning algorithm. ML-based database tuning. OtterTune [49] uses Gaussian processes with workload mapping and LASSO-based parameter selection, implicitly assuming that importance decomposes into independent per-parameter contributions. CDBTune [55] applies deep RL and can in principle capture correlations, but requires thousands of trials to do so. ResTune [56] ensembles multiple GP models and LlamaTune [21] reduces dimensionality via random projection; neither explicitly models interaction structure. Hunter [9] transfers tuning knowledge across workloads, assuming that parameter importance is portable across contexts. These systems focus on improving the search algorithm while treating the knowledge source as fixed. P ERF E VOLVE is orthogonal: it improves the knowledge that feeds any such algorithm, as our controlled experiments (§4) confirm. Configuration correlation analysis. ConfigCrusher [50], ConEx [22], and SPLConqueror [44] characterize parameter correlations for debugging and understanding but do not translate findings into tuning guidance. P ERF E VOLVE closes this gap: it uses factorial ANOVA for correlation screening and encodes the discovered topology into executable skills that drive an optimization agent. Operational knowledge management. The SRE community has developed runbooks, playbooks, and incident response procedures that encode operational knowledge in semi-structured form [8]. Recent work explores LLM-based runbook execution [45]. These efforts share P ERF E VOLVE’s philosophy of procedural knowledge but target incident response rather than performance tuning, and lack the calibration that grounds P ERF E VOLVE’s decision criteria.

7

Conclusion

Today’s system tuning guides capture what experts conclude but discard how they reason. We argue for a paradigm shift: documentation should encode how to determine the right configuration, not merely what the right configuration is. P ERF E VOLVE is a tool that translates tuning methodologies into actionable skills, empowering LLM-based agents for efficient and effective tuning. We believe grounding tuning knowledge in reproducible process is the essential first step toward agentic tuning. 17

References [1] FreeBSD Documentation, 2026. URL https://docs.freebsd.org/. [2] MySQL Reference Manual: Chapter 10 Optimization, 2026. URL https://dev.mysql.com/ doc/refman/8.4/en/optimization.html. [3] Redis configuration parameters, 2026. URL https://redis.io/docs/latest/develop/ ai/search-and-query/administration/configuration/. [4] Optimizing Redis, 2026. URL https://redis.io/docs/latest/operate/oss_and_ stack/management/optimization/. [5] Windows technical documentation for developers and IT pros, 2026. URL https://learn. microsoft.com//windows/. [6] Apache Software Foundation. Apache Kafka 3.6 Documentation, 2026. URL https://kafka. apache.org/documentation/#3.6. [7] Yoav Benjamini and Yosef Hochberg. Controlling the false discovery rate: A practical and powerful approach to multiple testing. Journal of the Royal Statistical Society. Series B (Methodological), 57(1):289–300, 1995. [8] Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016. URL http: //landing.google.com/sre/book.html. [9] Baoqing Cai, Yu Liu, Ce Zhang, Guangyu Zhang, Ke Zhou, Li Liu, Chunhua Li, Bin Cheng, Jie Yang, and Jiashu Xing. Hunter: An online cloud database hybrid tuning system for personalized requirements. In Proceedings of the 2022 International Conference on Management of Data, SIGMOD ’22, page 646–659, 2022. doi: 10.1145/3514221.3517882. [10] Sibei Chen, Ju Fan, Bin Wu, Nan Tang, Chao Deng, Pengyi Wang, Ye Li, Jian Tan, Feifei Li, Jingren Zhou, and Xiaoyong Du. Automatic database configuration debugging using retrievalaugmented language models. Proc. ACM Manag. Data, 3(1), 2025. doi: 10.1145/3709663. [11] Jacob Cohen. Statistical Power Analysis for the Behavioral Sciences. Lawrence Erlbaum Associates, 2nd edition, 1988. [12] Benoît Dageville and Mohamed Zait. Sql memory management in oracle9i. In Proceedings of the 28th International Conference on Very Large Data Bases, VLDB ’02, page 962–973. VLDB Endowment, 2002. [13] Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe Cudré-Mauroux. OLTPBench: An extensible testbed for benchmarking relational databases. In Proc. VLDB Endow., volume 7, page 277–288, 2013. doi: 10.14778/2732240.2732246. [14] Songyun Duan, Vamsidhar Thummala, and Shivnath Babu. Tuning database configuration parameters with ituned. In Proc. VLDB Endow, volume 2, page 1246–1257, August 2009. doi: 10.14778/1687627.1687767. [15] Victor Giannakouris and Immanuel Trummer. λ-tune: Harnessing large language models for automated database system tuning. Proc. ACM Manag. Data, 3(1), 2025. doi: 10.1145/3709652. [16] Shibo Hao, Yi Gu, Haodi Ma, Joshua Jiahua Hong, Zhen Wang, Daisy Zhe Wang, and Zhiting Hu. Reasoning with language model is planning with world model. In The 2023 Conference on Empirical Methods in Natural Language Processing, 2023. [17] Xinmei Huang, Haoyang Li, Jing Zhang, Xinxin Zhao, Zhiming Yao, Yiyan Li, Tieying Zhang, Jianjun Chen, Hong Chen, and Cuiping Li. E2ETune: End-to-end knob tuning via fine-tuned generative language model. In Proc. VLDB Endow., 2025. [18] Frank Hutter, Holger H. Hoos, and Kevin Leyton-Brown. Sequential model-based optimization for general algorithm configuration. In Proceedings of the 5th International Conference on Learning and Intelligent Optimization, LION’05, page 507–523, 2011. doi: 10.1007/ 978-3-642-25566-3_40. [19] Alexander Jung, Cezar Crăciunoiu, Nikolaos Karaolidis, Hugo Lefeuvre, Daniel Oñoro Rubio, Felipe Huici, Charalampos Rotsos, and Pierre Olivier. Wayfinder: Automated operating system specialization. In Proceedings of the 21st European Conference on Computer Systems, EUROSYS ’26, page 710–727. ACM, April 2026. doi: 10.1145/3767295.3803589. URL http://dx.doi.org/10.1145/3767295.3803589. 18

[20] Konstantinos Kanellis, Ramnatthan Alagappan, and Shivaram Venkataraman. Too many knobs to tune? towards faster database tuning by pre-selecting important knobs. In Proceedings of the 12th USENIX Conference on Hot Topics in Storage and File Systems, HotStorage ’20, 2020. [21] Konstantinos Kanellis, Cong Ding, Brian Kroth, Andreas Müller, Carlo Curino, and Shivaram Venkataraman. LlamaTune: Sample-efficient DBMS configuration tuning. In Proc. VLDB Endow., volume 15, page 2953–2965, 2022. doi: 10.14778/3551793.3551844. [22] Rahul Krishna, Chong Tang, Kevin Sullivan, and Baishakhi Ray. ConEx: Efficient exploration of big-data system configurations for better performance. In IEEE Transactions on Software Engineering, volume 48, pages 893–909, 2022. doi: 10.1109/TSE.2020.3007560. [23] Brian Kroth, Sergiy Matusevych, and Yiwen Zhu. Autotuning systems: Techniques, challenges, and opportunities. In Companion of the 2025 International Conference on Management of Data, SIGMOD/PODS ’25, page 821–828, 2025. doi: 10.1145/3722212.3725638. [24] Mayuresh Kunjir and Shivnath Babu. Black or white? how to develop an autotuner for memorybased analytics. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, SIGMOD ’20, page 1667–1683, 2020. doi: 10.1145/3318464.3380591. [25] Daniël Lakens. Calculating and reporting effect sizes to facilitate cumulative science: a practical primer for t-tests and anovas. Frontiers in Psychology, 4:863, 2013. doi: 10.3389/fpsyg.2013. 00863. [26] Jiale Lao, Yibo Wang, Yufei Li, Jianping Wang, Yunjia Zhang, Zhiyuan Cheng, Wanghu Chen, Mingjie Tang, and Jianguo Wang. GPTuner: A manual-reading database tuning system via GPT-guided Bayesian optimization. In Proc. VLDB Endow., volume 17, pages 1939–1952, 2024. [27] Yiyan Li, Haoyang Li, Zhao Pu, Jing Zhang, Xinyi Zhang, Tao Ji, Luming Sun, Cuiping Li, and Hong Chen. Is large language model good at database knob tuning? a comprehensive experimental evaluation, 2024. URL https://arxiv.org/abs/2408.02213. [28] Yiyan Li, Haoyang Li, Jing Zhang, Renata Borovica-Gajic, Shuai Wang, Tieying Zhang, Jianjun Chen, Rui Shi, Cuiping Li, and Hong Chen. Agenttune: An agent-based large language model framework for database knob tuning. Proc. ACM Manag. Data, 3(6), 2025. doi: 10.1145/3769758. [29] Hongyu Lin, Yuchen Li, Haoran Luo, Kaichun Yao, Libo Zhang, Mingjie Xing, and Yanjun Wu. Os-r1: Agentic operating system kernel tuning with reinforcement learning, 2025. URL https://arxiv.org/abs/2508.12551. [30] Hongyu Lin, Yuchen Li, Haoran Luo, Kaichun Yao, Libo Zhang, Zhenghong Lin, Mingjie Xing, Yanjun Wu, and Carl Yang. Byos: Knowledge-driven large language models bring your own operating system more excellent, 2026. URL https://arxiv.org/abs/2503.09663. [31] Linux Kernel Developers. The kernel’s command-line parameters, 2026. URL https://docs. kernel.org/admin-guide/kernel-parameters.html. [32] Meta Platforms, Inc. RocksDB Documentation, 2026. URL https://github.com/ facebook/rocksdb/wiki. [33] Meta Platforms, Inc. RocksDB Tuning Guide, 2026. URL https://github.com/facebook/ rocksdb/wiki/RocksDB-Tuning-Guide. [34] Oracle Corporation. MySQL 8.0 Reference Manual, 2024. URL https://dev.mysql.com/ doc/refman/8.0/en/. [35] Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology, UIST ’23, 2023. doi: 10.1145/3586183.3606763. [36] Andrew Pavlo, Gustavo Angulo, Joy Arulraj, Haibin Lin, Jiexi Lin, Lin Ma, Prashanth Menon, Todd C. Mowry, Matthew Perron, Ian Quah, Siddharth Santurkar, Anthony Tomasic, Skye Toor, Dana Van Aken, Ziqi Wang, Yingjun Wu, Ran Xian, and Tieying Zhang. Self-driving database management systems. In Conference on Innovative Data Systems Research, 2017. [37] Andrew Pavlo, Matthew Butrovich, Lin Ma, Prashanth Menon, Wan Shen Lim, Dana Van Aken, and William Zhang. Make your database system dream of electric sheep: towards self-driving operation. Proc. VLDB Endow., 14(12):3211–3221, 2021. doi: 10.14778/3476311.3476411. 19

[38] Karl Pearson. Contributions to the mathematical theory of evolution. Philosophical Transactions of the Royal Society of London. A, 185:71–110, 1894. [39] PGTune. PGTune: Postgresql configuration wizard. https://pgtune.leopard.in.ua/, 2024. [40] PostgreSQL Global Development Group. PostgreSQL Documentation. URL https://www. postgresql.org/docs/18/. [41] Postgresqlco.nf. Postgresqlco.nf. https://postgresqlco.nf/, 2025. [42] Ankur Sharma, Felix Martin Schuhknecht, and Jens Dittrich. The case for automatic database administration using deep reinforcement learning, 2018. URL https://arxiv.org/abs/ 1801.05643. [43] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: language agents with verbal reinforcement learning. In Proceedings of the 37th International Conference on Neural Information Processing Systems, NIPS ’23, 2023. [44] Norbert Siegmund, Sergiy S. Kolesnikov, Christian Kästner, Sven Apel, Don Batory, Marko Rosenmüller, and Gunter Saake. Predicting performance via automated feature-interaction detection. In Proceedings of the 34th International Conference on Software Engineering, ICSE ’12, page 167–177. IEEE Press, 2012. [45] Bradley D Smith. An agent-graph workflow built with graph-flow in rust that parses markdown runbooks and executes them step-by-step, using a local llm (ollama) to understand intent and verify outcomes. https://github.com/bradleyd/runbook-executor, 2026. [46] Wenwen Sun, Zhicheng Pan, Zirui Hu, Yu Liu, Chengcheng Yang, Rong Zhang, and Xuan Zhou. Rabbit: Retrieval-augmented generation enables better automatic database knob tuning. In 2025 IEEE 41st International Conference on Data Engineering (ICDE), pages 3807–3820, 2025. doi: 10.1109/ICDE65448.2025.00284. [47] The PostgreSQL Global Development Group. PostgreSQL: Chapter 14. Performance Tips, 2026. URL https://www.postgresql.org/docs/current/performance-tips.html. [48] Immanuel Trummer. Db-bert: A database tuning tool that "reads the manual". In Proceedings of the 2022 International Conference on Management of Data, SIGMOD ’22, page 190–203, 2022. doi: 10.1145/3514221.3517843. [49] Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, and Bohan Zhang. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 International Conference on Management of Data, SIGMOD ’17, pages 1009–1024, 2017. doi: 10.1145/3035918.3064029. [50] Miguel Velez, Pooyan Jamshidi, Florian Sattler, Norbert Siegmund, Sven Apel, and Christian Kästner. ConfigCrusher: Towards white-box performance analysis for configurable systems. In Automated Software Engg., volume 27, page 265–300. Kluwer Academic Publishers, 2020. doi: 10.1007/s10515-020-00273-8. [51] Francesco Ventura, Zoi Kaoudi, Jorge Arnulfo Quiané-Ruiz, and Volker Markl. Expand your training limits! generating training data for ml-based data management. In Proceedings of the 2021 International Conference on Management of Data, SIGMOD ’21, page 1865–1878, 2021. doi: 10.1145/3448016.3457286. [52] Zihao Wang, Shaofei Cai, Guanzhou Chen, Anji Liu, Xiaojian Ma, Yitao Liang, and Team CraftJarvis. Describe, explain, plan and select: interactive planning with large language models enables open-world multi-task agents. In Proceedings of the 37th International Conference on Neural Information Processing Systems, NIPS ’23, 2023. [53] Xinyue Yang, Chen Zheng, Yaoyang Hou, Renhao Zhang, Yinyan Zhang, Yanjun Wu, and Heng Zhang. L2t-tune:llm-guided hybrid database tuning with lhs and td3, 2025. URL https://arxiv.org/abs/2511.01602. [54] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In 11th International Conference on Learning Representations, ICLR ’23, 2023. [55] Ji Zhang, Yu Liu, Ke Zhou, Guoliang Li, Zhili Xiao, Bin Cheng, Jiashu Xing, Yangtao Wang, Tianheng Cheng, Li Liu, Minwei Ran, and Zekang Li. An end-to-end automatic cloud database 20

tuning system using deep reinforcement learning. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD ’19, page 415–432, 2019. doi: 10.1145/3299869. 3300085. [56] Xinyi Zhang, Hong Wu, Zhuo Chang, Shuowei Jin, Jian Tan, Feifei Li, Tieying Zhang, and Bin Cui. ResTune: Resource oriented tuning boosted by meta-learning for cloud databases. In Proceedings of the 2021 International Conference on Management of Data, SIGMOD ’21, page 2102–2114, 2021. doi: 10.1145/3448016.3457291. [57] Xinyi Zhang, Zhuo Chang, Yang Li, Hong Wu, Jian Tan, Feifei Li, and Bin Cui. Facilitating database tuning with hyper-parameter optimization: a comprehensive experimental evaluation. Proc. VLDB Endow., 15(9):1808–1821, 2022. doi: 10.14778/3538598.3538604. [58] Xuanhe Zhou, Guoliang Li, Zhaoyan Sun, Zhiyuan Liu, Weize Chen, Jianming Wu, Jiesi Liu, Ruohang Feng, and Guoyang Zeng. D-Bot: Database diagnosis system using large language models. In Proc. VLDB Endow., volume 17, 2024. doi: 10.14778/3675034.3675043. [59] Xuanhe Zhou, Zhaoyan Sun, and Guoliang Li. DB-GPT: Large language model meets database. In Data Science and Engineering, volume 9, page 102—111, 2024. doi: 10.1007/s41019-023-00235-6. [60] Yuqing Zhu, Jianxun Liu, Mengying Guo, Yungang Bao, Wenlong Ma, Zhuoyue Liu, Kunpeng Song, and Yingchun Yang. Bestconfig: tapping the performance potential of systems via automatic configuration tuning. In Proceedings of the 2017 Symposium on Cloud Computing, SoCC ’17, page 338–350, 2017. doi: 10.1145/3127479.3128605.

21