SynQL: A Controllable and Scalable Rule-Based Framework for SQL Workload Synthesis for Performance Benchmarking Kahan Mehta1⋆ and Amit Mankodi1
arXiv:2604.08021v1 [cs.DB] 9 Apr 2026
School of Technology, Dhirubhai Ambani University, Gandhinagar, Gujarat, India [email protected], amit [email protected]
Abstract. Database research and the development of learned query optimisers rely heavily on realistic SQL workloads. Acquiring real-world queries is increasingly difficult, however, due to strict privacy regulations, and publicly released anonymised traces typically strip out executable query text to preserve confidentiality. Existing synthesis tools fail to bridge this training-data gap: traditional benchmarks offer too few fixed templates for statistical generalisation, while Large Language Model (LLM) approaches suffer from schema hallucination—fabricating nonexistent columns—and topological collapse—systematically defaulting to simplistic join patterns that fail to stress-test query optimisers. We propose SynQL, a deterministic workload synthesis framework that generates structurally diverse, execution-ready SQL workloads. As a foundational step toward bridging the training-data gap, SynQL targets the core SQL fragment—multi-table joins with projections, aggregations, and range predicates—which dominates analytical workloads. SynQL abandons probabilistic text generation in favour of traversing the live database’s foreign-key graph to populate an Abstract Syntax Tree (AST), guaranteeing schema and syntactic validity by construction. A configuration vector Θ provides explicit, parametric control over join topology (Star, Chain, Fork), analytical intensity, and predicate selectivity. Experiments on TPC-H and IMDb show that SynQL produces near-maximally diverse workloads (Topological Entropy H = 1.53 bits) and that treebased cost models trained on the synthetic corpus achieve R2 ≥ 0.79 on held-out synthetic test sets with sub-millisecond inference latency, establishing SynQL as an effective foundation for generating training data when production logs are inaccessible. Keywords: Query Execution Time · SQL Workload Synthesis · Learned Cost Models · Topological Diversity · Synthetic Benchmarks
1
Introduction
Modern cloud databases and learned query optimisers depend on large, representative SQL workloads to guide system tuning, evaluate performance, and ⋆
Corresponding author.
2
K. Mehta and A. Mankodi
train cost-estimation models. Obtaining such workloads from production systems is increasingly difficult: privacy regulations, security protocols, and data governance constraints prevent the research community from accessing queries that contain sensitive intellectual property or personally identifiable information. This challenge mirrors the broader data-access barriers observed across domains— from healthcare to finance—where synthetic data generation has emerged as a principled alternative to real data when privacy constraints are binding [1]. Cloud vendors have responded by releasing anonymised traces—Snowset [2] and Redset [3] are notable examples—but these artefacts retain only high-level execution statistics (CPU time, bytes scanned) and deliberately omit the original SQL text and underlying data. The traces are therefore not executable and cannot be used to train machine learning models directly. Researchers who wish to train learned database components are left with two inadequate alternatives. The first is fixed benchmarks: TPC-H and TPC-DS provide 22 and 99 hand-crafted query templates, respectively [4, 5]. Training on so narrow a template set leads to catastrophic overfitting and fails to capture the complex, long-tailed distributions observed in production. The Join Order Benchmark (JOB) [6] improves realism by introducing real-world data skew, yet its template count remains small, and its 2025 revisitation [7] confirms that optimizer gains over the last decade remain marginal for structurally atypical queries. The second alternative is generative LLMs: because LLMs treat SQL generation as a probabilistic token-prediction task rather than a constrained graph-routing problem, they exhibit schema hallucination (fabricating non-existent columns or tables) and topological collapse (defaulting to simplistic hub-and-spoke star joins that dominate pre-training corpora). Spider 2.0 documents a drop in GPT-4o’s success rate from 86.6% on simple schemas to just 10.1% on enterprise SQL [8], and BIRD confirms execution accuracy below 40% on complex schemas [9]. To overcome these limitations we propose SynQL (Synthetic Query Language workload generator), a fine-grained synthesis framework that replaces probabilistic generation with deterministic schema-graph traversal. By constructing queries node-by-node from the target database’s live foreign-key catalog and assembling them into an Abstract Syntax Tree (AST), SynQL guarantees 100% schema and syntactic validity by construction, mechanically bypassing the hallucination risks of autoregressive models. A configuration vector Θ provides explicit parametric control over join topology, analytical intensity, and predicate selectivity, enabling practitioners to synthesise massive, structurally diverse training datasets without hand-authoring a single template. The remainder of the paper is organised as follows. Section 2 surveys related work. Section 3 presents the SynQL framework, including its two-phase pipeline, algorithms, and configuration parameters. Section 4 details the experimental setup and case studies. Section 5 reports results. Section 6 discusses limitations, and Section 7 concludes.
SynQL: Controllable SQL Workload Synthesis
2
3
Related Work
Our framework addresses limitations at the intersection of three active research areas: benchmark coverage for learned systems, generalisation in learned query optimisation, and the structural constraints of automated SQL synthesis. 2.1
The Training-Data Barrier: Industrial Needs vs. Static Benchmarks
The industrial viability of tree-based query execution time (QET) prediction is definitively demonstrated by Amazon’s Stage predictor [10]. Deployed as a hierarchical XGBoost ensemble across Redshift instances, Stage achieves a 20% average latency reduction in production while making the data-access barrier explicit: its local models are trained on massive logs of customer-specific production queries that academic practitioners cannot replicate. Standard benchmarks such as TPC-H and TPC-DS are structurally insufficient substitutes; their fixed template sets are too narrow for statistical generalisation. The JOB-Complex challenge [11] provides further evidence that structurally atypical queries—precisely those absent from standard benchmarks—cause the most severe performance regressions in modern systems. 2.2
Learned Optimisation and Generalisation Bottlenecks
End-to-end QET prediction depends critically on cardinality estimation. The field has evolved from early deep-learning estimators such as MSCN [12] and NeuroCard [13] through joint plan-cost networks [14] and reinforcement-learningbased optimisers such as Bao [15] and Balsa [16]. Despite these architectural advances, a universal limitation persists: model performance generalises poorly to structurally novel queries absent from training data. LIMAO [17] attempts to address this through a lifelong modular architecture, yet the survey by Zhu et al. [18] concludes that training-data quality remains the single most consequential factor in model generalisation. Sun et al.’s comparative study [19] further shows that no single estimator dominates across all execution regimes. SynQL directly targets this bottleneck: the Pwhere and αshape parameters are designed to generate the estimation regimes and topological edge cases that trained models most often lack. 2.3
Failure Modes of LLM-Based SQL Synthesis
The community has explored LLMs for workload synthesis, but empirical benchmarks reveal severe mechanical limitations when tasked with structural SQL generation. Spider 2.0 [8] attributes GPT-4o’s sharp accuracy drop on enterprise SQL to schema hallucination and dialect confusion. Scale-driven evaluations in BIRD [9] and PARROT [20] confirm execution accuracy below 40% on complex schemas. The survey by Hong et al. [21] identifies two persistent failure modes in
4
K. Mehta and A. Mankodi
autoregressive SQL generation: schema compliance failures and structural rigidity driven by training-corpus bias. Because hallucination and topological collapse rates are unacceptably high for automated data generation, SynQL is proposed as a constructive, graph-based alternative that mathematically bypasses these flaws to guarantee strict validity.
3
The SynQL Framework
This section presents the complete SynQL design. Section 3.1 provides an architectural overview and introduces the notation used throughout. Sections 3.2 and 3.3 detail the two core algorithms. Section 3.4 describes how these algorithms compose into the workload generation loop. Section 3.5 explains the configuration vector Θ, and Section 4.1 illustrates the framework with a concrete example.
3.1
Architectural Overview
SynQL is a deterministic, two-phase constructive pipeline framework that bypasses text-based probabilistic generation entirely. Given a target database’s live catalog, the framework operates as follows (Figure 1): 1. Phase I (Topological Traversal). The relational schema graph is traversed to produce a join subgraph whose shape is controlled by the topology-bias parameter αshape . The output is a join blueprint: the set of active tables and the edges connecting them. 2. Phase II (Semantic Injection & AST Assembly). Projections, aggregations, and predicates are injected into the blueprint and compiled into an Abstract Syntax Tree (AST), producing an executable SQL string with guaranteed schema and syntactic validity. To generate a workload of N queries, SynQL simply repeats Phase I and Phase II in sequence N times under a shared configuration vector Θ. Table 1 summarises all symbols and operations used in SynQL.
3.2
Phase I: Topological Traversal
The goal of Phase I is to construct a valid relational subgraph whose shape reflects the topology bias dictated by αshape . Algorithm 1 formalises the procedure. Schema Graph and Initialisation. SynQL ingests the database catalog to instantiate the relational schema graph S = (V, E), where V represents tables and E represents PK-FK constraints. A root table Tbase is sampled uniformly at random and a target join depth Njoin ∼ U (1, Kjoin ) is drawn.
SynQL: Controllable SQL Workload Synthesis
5
Table 1. Notation and terminology used in the SynQL algorithms. Symbol / Term Schema and graph terms S = (V, E) Tbase Tused Jq Jposs Tin , Tout dist(v, Tbase ) Dmax w(e) I(·)
Description Schema graph: V is the set of tables, E is the set of primary-key to foreign-key (PK-FK) edges Root table selected uniformly at random to start the join traversal Set of tables visited so far during graph traversal Set of join edges selected for the current query Candidate edge set: all non-cyclic PK-FK edges from visited to unvisited tables For a candidate edge e: Tin is the already-visited (anchor) table; Tout is the unvisited table Shortest-path edge distance from table v to the root Current maximum depth: maxv∈Tused dist(v, Tbase ) Selection weight assigned to candidate edge e (Eq. 1) Indicator function: returns 1 if the condition is true, 0 otherwise
Configuration parameters (Θ) Topology bias: steers traversal toward Star (αshape → 1) or αshape Chain (αshape → 0) topologies Kjoin Maximum number of join edges per query (controls table count) Njoin Sampled join depth for one query: Njoin ∼ U (1, Kjoin ) Pagg Probability that a numeric column is wrapped in an aggregation function (SUM or AVG) Pwhere Probability that a WHERE clause is added to the query Kpred Maximum number of predicates in the WHERE clause Query-construction terms Cselect Cgroup by Pfilters has agg AST
Accumulated SELECT-list entries (columns or aggregated expressions) Set of non-aggregated columns requiring a GROUP BY entry Set of generated predicate expressions for the WHERE clause Boolean flag: True if at least one aggregation has been injected Abstract Syntax Tree representing the SQL query under construction
Operations UniformRandom(A) Draw one element uniformly at random from set A WeightedRandomChoice(S, w) Draw one element from set S with probability proportional to weights w SampleColumns(T ) Return a random subset of catalog columns from table T SampleCatalogDomain(c) Sample a domain-valid value for column c from database statistics IsNumeric(c) Return True if column c has a numeric data type AggFunc(c) Wrap column c in a randomly chosen aggregation function (SUM or AVG) CompileToSQLString(AST ) Serialize the AST into an executable SQL string
6
K. Mehta and A. Mankodi Config Θ: αshape , Kjoin , Pagg , Pwhere , Kpred
Database Catalog S = (V, E)
Phase I Topological Traversal (Alg. 1) FK-graph walk, αshape -weighted edge selection repeat N times
Join Blueprint (Tused , Jq )
Phase II Semantic Inj. + AST Assembly
SQL Query qi
Workload Q (N queries)
(Alg. 2) Column sampling, aggregation, predicates, AST compilation
Fig. 1. SynQL pipeline overview. The database catalog feeds Phase I (Algorithm 1), which produces a join blueprint under topology bias αshape . Phase II (Algorithm 2) injects semantic content and compiles each query via an AST. Configuration vector Θ governs both phases; the outer loop repeats them N times to emit workload Q.
Iterative Edge Selection. At each expansion step the algorithm identifies Jposs , the set of all valid, non-cyclic PK-FK edges extending from already-visited tables to unvisited tables. For a candidate edge e connecting an active anchor Tin ∈ Tused to an unvisited table Tout ∈ / Tused , the selection weight is: if Dmax = 0, 1 w(e) = dist(Tin , Tbase ) αshape · I(Tin = Tbase ) + (1 − αshape ) · if Dmax > 0, Dmax (1) During the first join step (Dmax = 0) all candidate edges receive equal weight to ensure unbiased root expansion. On subsequent steps, the bias parameter steers the topology as illustrated in Figure 2: – αshape → 1: heavily weights edges returning to the root, producing wide Star topologies; – αshape → 0: favours deepest-frontier expansion, producing deep Chain topologies; – Intermediate values yield Fork (hybrid) topologies. Because the traversal follows actual FK constraints, every generated join is semantically valid by construction. 3.3
Phase II: Semantic Injection and AST Assembly
Given the join blueprint (Tused , Jq ) produced by Phase I, Phase II populates the query with semantic content and compiles it into an executable SQL string. Algorithm 2 formalises the three sub-steps. Step 1: Analytical Injection. For each table T ∈ Tused , SynQL samples a random subset of catalog columns. Each numeric column is wrapped in an aggregation function (SUM or AVG) with probability Pagg . Any column that is not aggregated is automatically enrolled in the Cgroup by set. This invariant guarantees syntactic
SynQL: Controllable SQL Workload Synthesis Star (αshape → 1)
Fork (αshape ≈ 0.5)
Chain (αshape → 0)
R
R
R
T1
T2
T3
T4
T1
T2
T3
T4
7
T1
T2
T3
Fig. 2. Effect of αshape on join topology. High values attach all tables to the root R (Star); low values extend the deepest frontier (Chain); intermediate values produce branching Forks.
validity: every non-aggregated column in the SELECT list will have a corresponding GROUP BY entry, mechanically eliminating the “unaggregated column” errors that plague LLM-based generators. Step 2: Predicate Injection. With probability Pwhere , a WHERE clause is added. Up to Kpred range or equality predicates are generated using domain-aware values sampled from the database’s statistics catalog (e.g., c > val ), ensuring that predicates reference valid column domains. Step 3: AST Compilation. The accumulated state—projections, join edges, predicates, and grouping columns—is mapped into a relational AST that enforces strict SQL grammar rules, making syntactic errors mechanically impossible. If Cgroup by is non-empty and at least one aggregation is present, a GROUP BY clause is automatically appended. Optional ORDER BY and LIMIT clauses are attached before the AST is compiled into an SQL string. 3.4
Workload Generation Loop
Algorithms 1 and 2 together produce a single executable query. To generate a full workload Q of N queries, SynQL executes them in sequence inside a simple outer loop: 1. Reset. All per-query state (Tused , Jq , Cselect , Cgroup by , Pfilters , has agg) is cleared. 2. Phase I. Algorithm 1 is invoked with the shared configuration parameters (αshape , Kjoin ) to produce a fresh join blueprint. 3. Phase II. Algorithm 2 receives the blueprint and the remaining parameters (Pagg , Pwhere , Kpred ) to emit query qi . 4. Enqueue. qi is appended to Q.
8
K. Mehta and A. Mankodi
Algorithm 1: Phase I: Topological Graph Traversal. All symbols are defined in Table 1. Input: Schema graph S = (V, E), max join depth Kjoin , topology bias αshape Output: Active table set Tused , join edge set Jq 1 Tbase ← UniformRandom(V) 2 Tused ← {Tbase }; Jq ← ∅ 3 Njoin ← UniformRandom(1, Kjoin ) // target join count 4 while |Jq | < Njoin do 5 Jposs ← {(Ta , Tb ) ∈ E | (Ta ∈ Tused ) ⊕ (Tb ∈ Tused )} // non-cyclic FK edges 6 if Jposs = ∅ then break // schema exhausted 7
Dmax ← maxv∈Tused dist(v, Tbase ) // current max depth for each e ∈ Jposs do 10 Tin ← e ∩ Tused // anchor table 11 Compute w(e) via Eq. (1) using Tin , Tbase , Dmax , αshape 12 end 13 e∗ = (Ta , Tb ) ← WeightedRandomChoice(Jposs , w) 14 Jq ← Jq ∪ {e∗ }; Tused ← Tused ∪ {Ta , Tb } 15 end 16 return Tused , Jq 8
9
Because each iteration draws a new root table uniformly at random, schema-wide table coverage is ensured over large workloads. The procedure runs in O(N · Kjoin ) time; the full 20,000-query corpus used in our experiments (Section 4) was generated in under ten minutes on the target hardware. Figure 3 traces a single iteration of this loop on the IMDb schema, showing the concrete data flow from root-table selection through join expansion, column sampling, and final AST compilation into an executable SQL string. 3.5
Configuration Vector Θ: Optimizer Stress Dimensions
Each parameter in Θ targets a distinct, known failure mode of query optimisers. Table 2 provides a compact summary. αshape and Kjoin —Topology and Join Depth. αshape controls the attachment bias of each new join edge. High values (αshape → 1) produce Star schemas, stressing fact-dimension join ordering—the regime where Bao [15] and Balsa [16] achieve their largest gains over PostgreSQL. Low values (αshape → 0) produce deep Chain queries, where estimation errors compound multiplicatively—the scenario JOB-Complex [11] identifies as most damaging for current learned optimisers. Kjoin caps graph depth, bounding the join-ordering search space per query. Pagg —Analytical Intensity. High Pagg generates OLAP-style queries with aggregation functions, forcing the optimiser to choose between HashAggregate
SynQL: Controllable SQL Workload Synthesis
9
Phase I: Topological Traversal (Alg. 1) 1. Select root table Tbase ← UniformRandom(V) ⇒ title 2. Sample join depth Njoin ∼ U (1, Kjoin = 3) ⇒ Njoin = 3 3. Expand join edges (× 3 iterations) αshape = 0.1 (chain bias): each step favours the deepest frontier, suppressing root-attachment edges
Resulting join subgraph (chain topology): person id
movie id
t
⇓
ci
role id
n
cn
blueprint (Tused , Jq ) passed to Phase II
Phase II: Semantic Injection + AST Assembly (Alg. 2) 4. Column sampling + aggregation Pagg = 1.0 t.title → Cselect , cn.name → COUNT(·) ⇒ has agg = True 5. Predicate injection Pwhere = 0.4 (triggered) Sampled: t.production year > 2010 from catalog domain 6. AST compilation has agg ∧ Cgroup by ̸= ∅ ⇒ autoappend GROUP BY t.title Attach ORDER BY, LIMIT → CompileToSQLString(AST) SELECT t.title, COUNT(cn.name) FROM title t JOIN cast info ci ON t.id = ci.movie id JOIN name n ON ci.person id = n.id JOIN char name cn ON ci.person role id = cn.id WHERE t.production year > 2010 GROUP BY t.title;
Output: qi appended to workload Q
Fig. 3. Detailed walkthrough of a single SynQL iteration on the IMDb schema. Phase I (steps 1–3): root table title is selected, join depth 3 is sampled, and three αshape -weighted edge expansions produce a chain subgraph with FK join conditions shown on each edge. Phase II (steps 4–6): columns are sampled with full aggregation (Pagg = 1.0), a year predicate is injected, and the AST compiler auto-appends GROUP BY before emitting the executable SQL query.
10
K. Mehta and A. Mankodi
Algorithm 2: Phase II: Semantic Injection and AST Assembly. All symbols are defined in Table 1. Input: Join blueprint (Tused , Jq ) from Algorithm 1, configuration parameters Pagg , Pwhere , Kpred Output: Executable SQL query q 1 Cselect ← ∅; Cgroup by ← ∅; Pfilters ← ∅; has agg ← False // Step 1: Analytical Injection for each T ∈ Tused do 3 for each c ∈ SampleColumns(T ) do 4 if IsNumeric(c) ∧ Rand() < Pagg then 5 Cselect ← Cselect ∪ {AggFunc(c)} 6 has agg ← True 7 else 8 Cselect ← Cselect ∪ {c} 9 Cgroup by ← Cgroup by ∪ {c} // enforce GROUP BY invariant 10 end 11 end 12 end 2
// Step 2: Predicate Injection if Rand() < Pwhere then 14 for each c ∈ SampleColumns(Tused , Kpred ) do 15 val ← SampleCatalogDomain(c) 16 Pfilters ← Pfilters ∪ {c > val } 17 end 18 end
13
// Step 3: AST Compilation AST ← InitNode(SELECT, Cselect ) 20 AttachNode(AST, FROM, Tused , Jq ) 21 if Pfilters ̸= ∅ then AttachNode(AST, WHERE, Pfilters ) 22 if has agg ∧ Cgroup by ̸= ∅ then AttachNode(AST, GROUP BY, Cgroup by ) 23 Optionally attach ORDER BY and LIMIT clauses 24 q ← CompileToSQLString(AST ) 25 return q 19
and GroupAggregate. This choice interacts non-linearly with available memory (work mem) and degree of parallelism—a dimension under-represented in standard fixed templates. Pwhere and Kpred —Predicate Selectivity. These parameters control the density and width of WHERE clauses, spanning the range from full-table scans to highly selective point lookups. Multi-predicate scenarios are precisely those where histogram statistics are most prone to the independence-assumption errors catalogued by Sun et al. [19].
SynQL: Controllable SQL Workload Synthesis
11
Table 2. Configuration vector Θ: parameters and their effects on workload characteristics.
4
Parameter
Symbol Range Optimiser stress target
Topology bias
αshape
[0, 1]
Join depth limit
Kjoin
Z+
Aggregation prob. Pagg
[0, 1]
Predicate prob.
Pwhere
[0, 1]
Predicate limit
Kpred
Z+
Star vs. Chain topology; joinorder search space Tables per query; cardinality error compounding OLAP intensity; Hash- vs. GroupAggregate choice Selectivity range; independenceassumption errors WHERE-clause width; multipredicate estimation
Experiments
All experiments were conducted on an Apple M1 workstation (8-core CPU, 16 GB unified memory) running PostgreSQL 14 [22] at default settings. Retaining the default configuration is a deliberate choice: SynQL is entirely schema-driven and generates corpora portable to any standard PostgreSQL deployment, aligning with the environment-adaptation requirements noted in recent learned cost-model studies [23]. The SynQL framework algorithms and machine learning pipeline were implemented in Python 3.9, using psycopg2 for database catalog interaction and scikit-learn [24] for model training. 4.1
Case Studies
The Θ configuration vector exposes five independently tunable dimensions. The four case studies below isolate specific parameter interactions to demonstrate the breadth of structural variation SynQL can produce, covering all three topology types on both benchmark schemas. Case Study 1: Star Join, Low Analytical Intensity (TPC-H). Setting αshape = 0.9, Kjoin = 3, and Pagg = 0.0 directs SynQL to generate a wide, flat star query with no aggregation—a projection-only scan of dimension tables through the central orders fact table. This configuration stresses the join-ordering component of the optimiser: all three dimension tables are equidistant from the root, so the planner must evaluate six possible join orderings with no aggregation operator to anchor its choice. Listing 1.1. Star query on TPC-H (αshape = 0.9, Kjoin = 3, Pagg = 0.0). 1 2 3 4 5
-- Case Study 1: TPC - H star , no a g g r e g a t i o n SELECT o . orderdate , c . mktsegment , s . name , n . name FROM orders o JOIN customer c ON o . custkey = c . custkey JOIN supplier s ON o . orderkey = s . suppkey
12 6 7
K. Mehta and A. Mankodi
JOIN nation n ON c . nationkey = n . nationkey WHERE o . orderdate > ’ 1995 -01 -01 ’;
Case Study 2: Chain Join, High Analytical Intensity (TPC-H). Setting αshape = 0.05, Kjoin = 4, and Pagg = 0.8 forces a deep five-table chain with heavy OLAP aggregation. The sequential join path means cardinality estimation errors compound multiplicatively at each step, and the dense SUM/AVG aggregations require the planner to make memory-sensitive decisions between HashAggregate and GroupAggregate—exactly the interaction under-represented in TPC-H’s 22 fixed templates. Listing 1.2. Chain query on TPC-H (αshape = 0.05, Kjoin = 4, Pagg = 0.8). 1 2 3 4 5 6 7 8 9 10 11 12
-- Case Study 2: TPC - H chain , high a g g r e g a t i o n SELECT n . name , r . name , SUM ( l . extendedprice ) AS total_revenue , AVG ( l . discount ) AS avg_discount FROM lineitem l JOIN orders o ON l . orderkey = o . orderkey JOIN customer c ON o . custkey = c . custkey JOIN nation n ON c . nationkey = n . nationkey JOIN region r ON n . regionkey = r . regionkey WHERE l . shipdate > ’ 1994 -01 -01 ’ GROUP BY n . name , r . name ORDER BY total_revenue DESC ;
Case Study 3: Fork Join, Multi-Predicate Selectivity (IMDb). Setting αshape = 0.5, Kjoin = 3, Pagg = 0.3, Pwhere = 1.0, and Kpred = 3 produces a branching fork topology on IMDb with multiple simultaneous filter predicates. The fork structure requires the planner to manage two independent join sub-trees hanging from the root, while three concurrent predicates expose the histogram independenceassumption errors documented by Sun et al. [19]. IMDb’s extreme data skew on title.production year amplifies this effect, making this configuration particularly informative for training cardinality estimators. Listing 1.3. Fork query on IMDb (αshape = 0.5, Kjoin = 3, Pwhere = 1.0, Kpred = 3). 1 2 3 4 5 6 7 8 9 10
-- Case Study 3: IMDb fork , multi - p r e d i c a t e SELECT t . title , mk . keyword , AVG ( mi . info ) AS avg_info FROM title t JOIN movie_keyword mk ON t . id = mk . movie_id JOIN movie_info mi ON t . id = mi . movie_id JOIN keyword k ON mk . keyword_id = k . id WHERE t . pr od uc t io n_ y ea r > 2005 AND t . kind_id = 1 AND mk . keyword_id < 5000 GROUP BY t . title , mk . keyword ;
Case Study 4: Deep Chain, Fully Analytical (IMDb). Setting αshape = 0.1, Kjoin = 4, Pagg = 1.0, and Pwhere = 0.0 generates a five-table linear chain on IMDb with every numeric column aggregated and no WHERE clause. The absence of predicates means the planner receives no selectivity signals to guide join reordering—all intermediate result sizes must be estimated from base-table
SynQL: Controllable SQL Workload Synthesis
13
Table 3. Summary of case studies and their optimiser stress targets. CS Schema αshape Kjoin Pagg Stress target 1 TPC-H
0.90
3
2 TPC-H
0.05
4
3 IMDb
0.50
3
4 IMDb
0.10
4
0.0 Join ordering without aggregate anchor 0.8 Compounding chain errors + OLAP agg. 0.3 Multi-predicate independence assumption 1.0 Full aggregation, no selectivity signal
statistics alone. This worst-case estimation scenario is compounded by IMDb’s skewed row distributions across the cast info–name–char name spine, and the full aggregation forces a GroupAggregate over the entire cross product before any filtering can reduce the working set. Listing 1.4. IMDb deep Chain query (αshape = 0.1, Kjoin = 4, Pagg = 1.0, Pwhere = 0.0). 1 2 3 4 5 6 7 8 9 10 11 12 13
-- CS4 : IMDb deep chain , fully analytical , SELECT t . title , SUM ( mi . info ) AS total_info , AVG ( mi . info ) AS avg_info , COUNT ( cn . name ) AS role_count FROM title t JOIN cast_info ci ON t . id = JOIN name n ON ci . person_id = JOIN char_name cn ON ci . person_ role_id = JOIN movie_info mi ON t . id = GROUP BY t . title ORDER BY role_count DESC LIMIT 100;
no p r e d i c a t e s
ci . movie_id n . id cn . id mi . movie_id
Table 3 summarises all four case studies, highlighting how each targets a distinct optimiser stress dimension absent or under-represented in standard benchmark template sets. 4.2
Workload Generation Using Benchmark Templates
Target Schemas. We validated SynQL against two schemas with strongly contrasting structural properties. TPC-H [4] is an 8-table normalised retail data warehouse schema representative of OLAP workloads. Its core structure centres on a lineitem– orders–customer spine, augmented by three dimension tables (supplier, part, partsupp) and a two-level geographical hierarchy (nation, region). The schema is acyclic and relatively shallow (maximum FK path depth of 4), making it a controlled baseline for assessing topological diversity: any workload generator that defaults to hub-and-spoke star patterns will over-weight joins through the orders fact table while neglecting the supplier and parts sub-graphs. SynQL’s αshape parameter explicitly breaks this bias by assigning traversal weights that promote chain and fork exploration across the full FK graph.
14
K. Mehta and A. Mankodi Table 4. SynQL configuration Θ for benchmark workload generation. Parameter
Symbol Value Effect
Join depth limit Kjoin Aggregation prob. Pagg Predicate prob. Pwhere Predicate limit Kpred Topology bias αshape
3 0.2 0.4 3 0.5
Up to 4 tables per query 20% OLAP-style queries 40% filtered queries Max WHERE conditions Balanced Star/Chain/Fork
IMDb (Join Order Benchmark) [6] is a 21-table real-world schema derived from the Internet Movie Database, characterised by extreme data skew, dense many-to-many relationships (e.g., title–cast info–name), and cyclical FK graphs that prevent naive tree-traversal strategies from covering the schema uniformly. The JOB benchmark [6, 7] uses 113 hand-crafted queries over this schema to expose cardinality estimation failures in modern optimisers; our SynQLgenerated corpus supplements these templates with 10,000 structurally diverse queries that systematically vary join depth, topology, and predicate selectivity. IMDb’s hub tables (title, cast info) attract high-degree FK connections, meaning that a star-biased generator will over-sample these nodes. SynQL counters this by tracking Tused and restricting re-entry, ensuring schema-wide table coverage even in the presence of dominant hub nodes. Workload Generation Configuration. SynQL synthesised 20,000 queries (10,000 per schema) using the balanced configuration shown in Table 4. The central value αshape = 0.5 was chosen to avoid skewing the generated distribution toward any single topology, producing a roughly balanced mix of Star, Chain, and Fork queries whose precise proportions are reported in Section 5.1. Kjoin = 3 bounds query width to at most four tables, matching the depth range of TPC-H’s most complex standard templates while remaining tractable for PostgreSQL’s join-order planner. The predicate parameters (Pwhere = 0.4, Kpred = 3) were selected to mirror the selectivity profile of the JOB workload, where approximately 40% of queries carry multi-column WHERE clauses. 4.3
Query Execution Time Prediction
Training Phase: Feature Engineering and Model Training. Ground-truth execution-time labels were collected by running the synthetic workload generated as described in section 4.2 through PostgreSQL’s EXPLAIN ANALYZE command. Input features were derived exclusively from pre-execution planner estimates, so that no post-execution statistics leak into the feature vector [14], preserving each model’s utility as a genuine pre-execution predictor. Table 5 enumerates the complete feature set. The dataset was split 80/20 for training and testing. We evaluated three treebased ensembles—Random Forest [25], XGBoost [26], and Gradient Boosting [27]— selected for their ability to model non-linear operator interactions, as validated
SynQL: Controllable SQL Workload Synthesis
15
by the industrial Stage predictor [10]. This choice of tree-based ensembles for tabular performance prediction aligns with recent findings that gradient-boosted models consistently outperform deep architectures on structured feature sets [28]. Performance is reported via RMSE, MAE, and R2 . Prediction Phase: Having established that SynQL produces structurally diverse, schema-valid workloads (Section 4.2), we now evaluate whether those workloads constitute effective training data for learned QET predictors. The experimental protocol follows the standard pre-execution prediction paradigm [14]: features are extracted from PostgreSQL’s EXPLAIN output (no post-execution statistics), and the target is the median wall-clock execution time (P50) measured over five repeated runs to suppress OS-level jitter. Execution time targets are log1p transformed before training to compress the heavy-tailed runtime distribution, with the inverse transform applied at inference. The complete results are reported in Section 5. Here we note three design decisions that distinguish this evaluation from prior synthetic-workload studies. First, the strict pre-execution feature constraint ensures that reported R2 values reflect genuine predictive performance, not post-hoc curve fitting. Second, the stratified 5-fold cross-validation protocol guards against topology imbalance inflating aggregate metrics. Third, the cross-topology transfer experiment (Section 5.3) directly tests whether topological diversity in the training corpus—SynQL’s core contribution—translates into robustness across query shapes.
16
K. Mehta and A. Mankodi
Table 5. Feature vector for QET prediction (21 features). All features are extracted from PostgreSQL’s EXPLAIN output (pre-execution). # Feature
Description
Planner cost estimates 1 plan total cost Estimated total cost of the root plan node 2 plan startup cost Estimated cost to return the first row 3 plan rows Estimated row count at the root node 4 plan width Estimated average row width (bytes) 5 max plan rows Maximum plan rows across all plan nodes Plan structural features 6 num plan nodes Total number of nodes in the plan tree 7 plan depth Depth (height) of the plan tree 8 num joins Number of join operators 9 num relations Number of base relations accessed 10 num predicates Number of filter / join predicates Operator-type counts 11 num seq scan Sequential Scan nodes 12 num index scan Index Scan / Index Only Scan nodes 13 num bitmap scan Bitmap Heap / Index Scan nodes 14 num hash join Hash Join nodes 15 num merge join Merge Join nodes 16 num nested loop Nested Loop join nodes Aggregate / GroupAggregate 17 num aggregate nodes 18 num sort Sort nodes 19 num limit Limit nodes 20 num materialize Materialize nodes 21 num gather Gather / Gather Merge (parallel) nodes
SynQL: Controllable SQL Workload Synthesis
5
Results and Discussion
5.1
Workload Characterisation and Topological Diversity
17
A primary design goal of SynQL is to prevent the topological collapse observed in LLM-based generators. We quantify structural diversity using Shannon Entropy (H) over the topological distribution (Star, Chain, Fork). As shown in Table 6, the SynQL-generated TPC-H workload achieves H = 1.53 bits, closely approaching the theoretical maximum for three categories (log2 3 ≈ 1.58 bits). SynQL produced a well-balanced mix of Chain (43.8%), Star (32.9%), and Fork (23.3%) topologies. For the IMDb schema, the generator appropriately reflected the database’s inherent hub-and-spoke connectivity, yielding a Star-dominant distribution (53.5%) and H = 1.34 bits. Both values substantially exceed the structural diversity afforded by the 22 static templates of the standard TPC-H benchmark. 5.2
Predictive Accuracy and Deployment Viability
Table 7 reports test-set performance of the learned QET predictors. To ensure statistical robustness, we performed stratified 5-fold cross-validation; the table shows results from the 80/20 held-out split, which fell within one standard deviation of the cross-validated means in all cases. On TPC-H, all three ensembles achieved R2 > 0.98, with XGBoost reaching 2 R = 0.987 (CV : 0.980 ± 0.004). On IMDb—a substantially harder schema due to extreme data skew and 27% query timeouts—Random Forest achieved the highest R2 = 0.824 (CV : 0.791 ± 0.035). The performance gap between schemas is expected: IMDb’s dense many-to-many relationships and highly variable execution times create a more challenging prediction landscape, consistent with the difficulties reported by the JOB benchmark [6, 7]. All three models executed with sub-millisecond inference latency, satisfying the strict overhead constraints required for deployment on a live query optimiser’s critical path. 5.3
Per-Topology Prediction Analysis
To validate that SynQL’s topological diversity translates into effective training signal across all join shapes, we classify each generated query’s topology by parsing its join graph from the SQL text: a query is labelled Star if all joins Table 6. Topological distribution of the 20,000-query SynQL corpus. Topology Chain Star Fork / Two-Table Entropy H
TPC-H (%) IMDb (%) 43.82 32.89 23.29
12.82 53.50 33.68
1.53 bits
1.34 bits
18
K. Mehta and A. Mankodi
Table 7. Model performance on held-out test sets (80/20 split). 5-fold CV R2 shown as mean ± std. TPC-H Model Random Forest XGBoost Gradient Boost
IMDb
RMSE MAE R 0.27 0.27 0.27
2
0.12 0.986 0.13 0.987 0.12 0.987
RMSE MAE R2 0.80 0.86 0.80
0.43 0.824 0.46 0.794 0.42 0.822
Table 8. Per-topology XGBoost performance on held-out test sets. Topology labels are derived from the SQL join graph. TPC-H Topology RMSE MAE R
IMDb 2
RMSE MAE R2
Star Chain Fork
0.24 0.30 0.24
0.12 0.990 0.14 0.982 0.12 0.976
1.08 0.77 0.80
0.59 0.671 0.28 0.862 0.44 0.818
All
0.27
0.13 0.987
0.86
0.46 0.794
attach to the root table (including two-table joins as degenerate stars), Chain if each successive table joins only to the previous one, and Fork otherwise. Table 8 disaggregates XGBoost’s predictions by topology class on the held-out test set. Each benchmark uses a held-out test set of 2 000 queries. On TPC-H, performance is uniformly high across all topologies (R2 ≥ 0.976), with Star queries being easiest (R2 = 0.990) and Chain queries hardest (R2 = 0.982)—consistent with chains producing compounding estimation errors. On IMDb, Chain queries achieve the highest R2 = 0.862 despite being the rarest topology (only 68 test queries), while Star queries are harder (R2 = 0.671) due to IMDb’s hub tables producing highly variable cardinalities. Fork queries dominate the IMDb test set (1 560 of 2 000) yet still reach R2 = 0.818, indicating that the model generalises well even for the most frequent topology. The results are striking. On TPC-H, a model trained exclusively on Fork queries yields R2 = −0.142 when tested on Star queries—worse than predicting the mean. On IMDb, the effect is even more pronounced: Star-trained models produce R2 = −1.313 on Chain queries. In every case, the mixed-topology model (“All”, bolded) matches or exceeds the best single-topology model on every test partition. This directly validates SynQL’s core design principle: topologically diverse training corpora are not merely desirable but necessary for robust cost prediction across the full range of query structures. 5.4
SynQL vs. LLM-Based Workload Generation
SynQL and LLM-based SQL generators address fundamentally different tasks— SynQL performs schema-driven workload synthesis for training data generation,
SynQL: Controllable SQL Workload Synthesis
19
whereas systems evaluated by Spider 2.0 [8] and BIRD [9] perform naturallanguage-to-SQL translation. A direct numerical comparison of success rates is therefore not meaningful. Nevertheless, the failure modes identified in these benchmarks are directly relevant to workload synthesis, because any generator that produces invalid or structurally homogeneous queries is unsuitable for training learned optimisers. Three properties distinguish SynQL’s constructive approach from LLM-based generation. Schema Validity. Spider 2.0 reports that GPT-4o’s success rate drops sharply on enterprise schemas due to schema hallucination and dialect confusion, while BIRD observes execution accuracy below 40% on complex schemas. By contrast, SynQL deterministically bounds generation to the database’s live foreign-key graph and enforces strict AST compliance (Section 3), achieving 100% schema validity and zero syntax errors across the entire 20,000-query corpus. Topological Diversity. LLMs probabilistically collapse toward simple star joins [20] because hub-and-spoke patterns dominate their pre-training corpora. The αshape parameter provides mathematical control over topology, enabling SynQL to synthesise deep join chains (43.8% on TPC-H) that expose the compound estimation errors causing performance regressions in learned optimisers [11]. Deterministic Reproducibility. Given identical Θ and random seed, SynQL produces byte-identical workloads, enabling controlled ablation studies. LLM outputs are inherently stochastic and sensitive to prompt phrasing, making experimental reproducibility difficult.
6
Limitations and Threats to Validity
We identify the following limitations of the current work, which also define concrete directions for improvement. SQL Coverage. SynQL is designed as a foundational framework targeting the core SQL fragment that dominates analytical workloads: multi-table SELECT queries with inner joins, projections, optional aggregations, and range predicates. This fragment accounts for the vast majority of queries in standard benchmarks (TPC-H, JOB) and captures the join-topology and selectivity dimensions most critical for stressing learned optimisers [11]. SynQL does not yet support correlated subqueries, EXISTS/IN clauses, Common Table Expressions (CTEs), set operations (UNION, INTERSECT), or HAVING clauses. Crucially, however, SynQL’s AST-based architecture is extensible by design: adding new clause types requires implementing additional AttachNode rules in Phase II without modifying the topological traversal of Phase I. We view the current work as establishing the core generation paradigm, with richer SQL constructs as a natural and modular extension.
20
K. Mehta and A. Mankodi
Database Engine Scope and Feature Portability. All experiments were conducted on PostgreSQL 14 [22]. It is important to distinguish two layers of engine dependence in SynQL’s design. The query generation layer (Phase I and Phase II) is fully engine-agnostic: it operates on the relational schema graph and emits standard SQL. The generated queries are syntactically portable to any SQL-compliant engine—we verified that the TPC-H corpus parses without errors on both PostgreSQL and SQLite. The feature extraction layer (Table 5), however, is tied to PostgreSQL’s EXPLAIN output format. Adapting SynQL’s ML pipeline to other engines requires mapping the 21 plan-level features to engine-specific equivalents. This is feasible for most targets: Spark SQL exposes analogous plan metadata via EXPLAIN EXTENDED, Snowflake provides query profiles with operator-level statistics, and MySQL’s EXPLAIN ANALYZE (available since 8.0) reports comparable operator counts and cost estimates. The core feature categories—planner cost estimates, plan structural features, and operator-type counts—have natural counterparts in all major engines, though the specific operator vocabulary differs (e.g., Snowflake uses TableScan rather than SeqScan). Validating this cross-engine feature mapping and measuring whether SynQL-trained cost models transfer across engines remains an important direction for future work. Schema Diversity. The evaluation covers two schemas (TPC-H and IMDb). While these represent contrasting structural properties (normalised warehouse vs. skewed real-world graph), the results may not generalise to schemas with substantially different characteristics, such as deeply nested hierarchies or very large table counts (>100 tables). Evaluation on Synthetic Data and Production Transfer. The R2 values reported in Section 5.2 reflect prediction accuracy on held-out synthetic test queries generated by SynQL itself. This evaluation design is deliberate: it establishes that the synthetic corpus provides a training signal of sufficient quality and diversity for accurate cost modelling—a necessary prerequisite before any production deployment. However, it does not directly measure transfer to real production workloads, which may exhibit distributional characteristics absent from the current generator (e.g., deeply nested subqueries, user-defined functions, highly skewed parameter distributions). We note that the production-transfer gap is a challenge shared by all synthetic workload generators, including fixed benchmarks like TPC-H. The key advantage of SynQL in this context is its parametric controllability: practitioners can tune Θ to approximate known characteristics of their production workload (e.g., high chain depth for OLTP-heavy systems, high Pagg for data-warehouse queries) without exposing proprietary SQL text. Validating this transfer pathway on anonymised production traces (e.g., Redset execution statistics) is a high-priority direction for future work. Topological Entropy Granularity. Shannon entropy is computed over three coarse topology categories (Star, Chain, Fork). This metric does not capture within-
SynQL: Controllable SQL Workload Synthesis
21
category variation (e.g., chain length distribution). A finer-grained diversity metric, such as graph-edit-distance-based measures, would provide a more nuanced characterisation.
7
Conclusion
We introduced SynQL, a deterministic workload synthesis framework designed to overcome the training-data scarcity that bottlenecks the deployment of learned database systems. By replacing probabilistic text generation with a two-phase constructive pipeline—schema-driven topological graph traversal followed by strict AST assembly—SynQL mechanically eliminates the schema hallucinations and syntax errors that severely limit LLM-based generators. Our evaluation demonstrates that the topological bias parameter αshape effectively prevents mode collapse: SynQL generated a 20,000-query corpus across TPC-H and IMDb achieving near-maximal topological entropy (H = 1.53 bits), natively producing the deep join chains and complex fork topologies absent from standard benchmarks. Tree-based cost models trained on this synthetic corpus achieved accurate execution time predictions (R2 ≥ 0.79 on held-out synthetic test sets, reaching 0.99 on TPC-H) with sub-millisecond inference latency. Crucially, our cross-topology transfer experiment (Section 5.3) demonstrates that models trained on a single topology fail catastrophically on other topologies (negative R2 ), while the mixed-topology corpus consistently yields the best performance across all shapes—directly validating SynQL’s core design principle that topological diversity in training data is not merely desirable but necessary. Four primary directions remain for future work. First, expanding the AST compiler to support correlated subqueries, EXISTS clauses, and Common Table Expressions (CTEs) would directly address the optimizer failure modes highlighted by JOB-Complex [11]; SynQL’s modular architecture makes this a natural extension without modifying Phase I. Second, validating the synthetic-to-production transfer pathway—by training models on SynQL-generated corpora and evaluating on anonymised production traces (e.g., Redset execution statistics)—would establish the strategic value of controllable synthesis for industrial deployment. Third, the structured relational trees produced during SynQL’s assembly phase are naturally suited for pre-training Graph Neural Networks for plan-cost estimation [14], offering richer representations than flat feature vectors. Finally, abstracting the AST layer to support multi-dialect generation (Spark SQL, Snowflake, BigQuery) and validating cross-engine feature mapping would cement SynQL’s industrial value: if a cost model trained on PostgreSQL-executed SynQL queries transfers to Spark or Snowflake plan features with minimal accuracy loss, it would demonstrate that synthetic workloads can serve as a universal training substrate across heterogeneous enterprise environments—the scenario documented in the Spider 2.0 challenge [8] and increasingly demanded by cloud-native data platforms [23].
Bibliography
[1] Halal Abdulrahman-Ahmed, Pau Baquero-Arnal, Javier Silvestre-Blanes, and Victor Sempere-Paya. Synthetic data generation for healthcare: Exploring generative adversarial networks variants for medical tabular data. International Journal of Data Science and Analytics, 20:5739–5754, 2025. https://doi.org/10.1007/s41060-025-00816-w. URL https://link. springer.com/article/10.1007/s41060-025-00816-w. [2] Benoit Dageville, Thierry Cruanes, Marcin Zukowski, Vadim Antonov, Artin Avanes, Jon Bock, Jonathan Claybaugh, Daniel Engovatov, Martin Isard, Speedy Joshi, et al. The Snowflake elastic data warehouse. In Proceedings of the 2016 ACM SIGMOD International Conference on Management of Data, pages 215–226, 2016. https://doi.org/10.1145/2882903.2903741. URL https://dl.acm.org/doi/10.1145/2882903.2903741. [3] Parimarjan Jain, Abhash Kumar Pokharel, Navneet Dhillon, Aaron Elmore, Ryan Marcus, and Tim Kraska. Is your data warehouse ready for AI? Redset: A large-scale, realistic benchmark from Redshift workloads. arXiv preprint arXiv:2411.07571, 2024. URL https://arxiv.org/abs/2411.07571. [4] Meikel Poess and Chris Floyd. New TPC benchmarks for decision support and web commerce. ACM SIGMOD Record, 29(4):64–71, 2000. URL https://dl.acm.org/doi/10.1145/373626.373714. [5] Raghunath Othayoth Nambiar and Meikel Poess. The making of TPC-DS. Proceedings of the VLDB Endowment, 32:999–1005, 2006. URL https: //dl.acm.org/doi/10.5555/1182635.1164217. [6] Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter Boncz, Alfons Kemper, and Thomas Neumann. How good are query optimizers, really? Proceedings of the VLDB Endowment, 9(3):204–215, 2015. URL http://www.vldb.org/ pvldb/vol9/p204-leis.pdf. [7] Viktor Leis and Thomas Neumann. Still asking: How good are query optimizers, really? Proceedings of the VLDB Endowment, 18:5531–5544, 2025. URL http://www.vldb.org/pvldb/vol18/p5531-viktor.pdf. [8] Fangyu Lei, Jixuan Chen, Yuxiao Ye, Ruisheng Cao, Dongchan Shin, Hongshen Su, Zhengyang Suo, Hongbin Gao, Wenjing Hu, Pengcheng Yin, et al. Spider 2.0: Evaluating language models on real-world enterprise text-to-SQL workflows, 2024. URL https://arxiv.org/abs/2411.07763. arXiv:2411.07763. [9] Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Ruiying Geng, Nan Huo, et al. Can LLM already serve as a database interface? A big bench for large-scale database grounded textto-SQLs. In Advances in Neural Information Processing Systems (NeurIPS), 2023. URL https://arxiv.org/abs/2305.03111. [10] Ziniu Wu, Ryan Marcus, Zhengchun Liu, Parimarjan Negi, Vikram Nathan, Pascal Pfeil, Gaurav Saxena, Mohammad Rahman, Balakrishnan Narayanaswamy, and Tim Kraska. Stage: Query execution time
SynQL: Controllable SQL Workload Synthesis
23
prediction in Amazon Redshift. In Companion of the 2024 International Conference on Management of Data (SIGMOD/PODS ’24), pages 1–15. ACM, 2024. https://doi.org/10.1145/3626246.3653391. URL https://doi.org/10.1145/3626246.3653391. [11] Jonas Wehrstein, Tobias Eckmann, Ruben Heinrich, and Carsten Binnig. JOB-Complex: A challenging benchmark for traditional & learned query optimization, 2025. URL https://arxiv.org/abs/2507.07471. arXiv:2507.07471. [12] Andreas Kipf, Thomas Kipf, Bernhard Radke, Viktor Leis, Peter Boncz, and Alfons Kemper. Learned cardinalities: Estimating correlated joins with deep learning. In CIDR, 2019. URL https://arxiv.org/abs/1809.00677. [13] Zongheng Yang, Amog Kamsetty, Shu Luan, Eric Liang, Yan Duan, Xi Chen, and Ion Stoica. NeuroCard: One cardinality estimator for all tables. Proceedings of the VLDB Endowment, 14(1):61–73, 2020. URL https://www.vldb.org/pvldb/vol14/p61-yang.pdf. [14] Ji Sun and Guoliang Li. An end-to-end learning-based cost estimator. Proceedings of the VLDB Endowment, 13(3):307–319, 2019. URL https: //www.vldb.org/pvldb/vol13/p307-sun.pdf. [15] Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Alizadeh, and Tim Kraska. Bao: Making learned query optimization practical. In Proceedings of ACM SIGMOD, pages 2177–2191, 2021. URL https: //dl.acm.org/doi/10.1145/3448016.3452711. [16] Zongheng Yang, Wei-Lin Chiang, Shu Luan, Michael Luo, and Ion Stoica. Balsa: Learning a query optimizer without expert demonstrations. In Proceedings of ACM SIGMOD, pages 931–944, 2022. URL https: //dl.acm.org/doi/10.1145/3514221.3517843. [17] Yuxing Chen, Ziniu Wu, and Tim Kraska. LIMAO: A framework for lifelong modular learned query optimization, 2025. URL https://arxiv.org/abs/ 2507.00188. arXiv:2507.00188. [18] Rong Zhu, Liang Chen, Shuai Wang, et al. A survey on learned query optimization. arXiv preprint arXiv:2404.02595, 2024. URL https://arxiv. org/abs/2404.02595. [19] Ji Sun, Jintao Zhang, Zhaoyan Sun, Guoliang Li, and Nan Tang. Learned cardinality estimation: A design space exploration and comparative evaluation. Proceedings of the VLDB Endowment, 15(1):85–97, 2021. URL https://www.vldb.org/pvldb/vol15/p85-sun.pdf. [20] Wei Zhou, Guoliang Li, Haoyu Wang, Yuxing Han, Xufei Wu, Fan Wu, and Xuanhe Zhou. PARROT: A benchmark for evaluating LLMs in cross-system SQL translation. In Advances in Neural Information Processing Systems (NeurIPS), 2025. URL https://arxiv.org/abs/2509.23338. [21] Zijin Hong, Zheng Yuan, Qinggang Zhang, Hao Chen, Junfeng Dong, Feiran Huang, and Xiao Huang. Next-generation database interfaces: A survey of LLM-based text-to-SQL. IEEE Transactions on Knowledge and Data Engineering, 2025. URL https://ieeexplore.ieee.org/document/ 10839257/.
24
K. Mehta and A. Mankodi
[22] The PostgreSQL Global Development Group. PostgreSQL 14 Documentation, 2021. URL https://www.postgresql.org/docs/14/. [23] Ruben Heinrich, Xin Li, Manuele Luthra, and Zoi Kaoudi. Learned cost models for query optimization: From batch to streaming systems. Proceedings of the VLDB Endowment, 18(12):5482–5487, 2025. URL https://www.vldb. org/pvldb/vol18/p5482-heinrich.pdf. [24] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al. Scikit-learn: Machine learning in Python. Journal of Machine Learning Research, 12:2825–2830, 2011. URL https: //jmlr.org/papers/v12/pedregosa11a.html. [25] Leo Breiman. Random forests. Machine Learning, 45(1):5–32, 2001. URL https://doi.org/10.1023/A:1010933404324. [26] Tianqi Chen and Carlos Guestrin. XGBoost: A scalable tree boosting system. In Proceedings of the 22nd ACM SIGKDD, pages 785–794, 2016. URL https://arxiv.org/abs/1603.02754. [27] Jerome H. Friedman. Greedy function approximation: A gradient boosting machine. Annals of Statistics, 29(5):1189–1232, 2001. URL https: //projecteuclid.org/euclid.aos/1013203451. [28] Hao Zhang and Jingyi Li. Online performance prediction using the fusion model of LightGBM and TabNet for large laser facilities. International Journal of Data Science and Analytics, 2024. https://doi.org/10.1007/ s41060-024-00686-8. URL https://link.springer.com/article/10. 1007/s41060-024-00686-8.