Dialect-Aware Query Reduction

• Dialect-aware query reduction is a method that isolates dialect-specific SQL features by simplifying complex queries through systematic AST pruning and LLM-guided minimalization.
• The approach extracts compact translation rules by retaining only the essential dialect constructs, enabling accurate SQL migration across heterogeneous RDBMSs.
• Empirical evaluations on benchmarks like TPC-DS show significant improvements in translation accuracy and efficiency compared to traditional rule-based and direct LLM methods.

Dialect-aware query reduction is a methodological approach for identifying and isolating SQL dialect-specific constructs within a complex query, with the explicit objective of simplifying the translation of SQL across heterogeneous relational database management systems (RDBMSs). This strategy is central to the RISE framework, which addresses limitations of both manually-crafted dialect rule engineering and LLM-based translation—particularly in the presence of lengthy, intricate SQL queries that challenge direct approaches. The reduction technique systematically produces a minimized yet faithful projection of the initial query, retaining only the elements essential to the dialect-specific translation task while discarding superfluous portions. This enables the derivation of minimal, generalizable translation rules which can be efficiently re-applied to the original query context (Xie et al., 9 Jan 2026).

1. Formal Definition and Goals

Given a source query $Q_c$ authored against an RDBMS $S$, and a target RDBMS $T$ where certain dialect-specific SQL features $d$ in $Q_c$ fail (as detected by error $E_d$), the aim of dialect-aware query reduction is to construct a simplified query $Q_s$. The reduction satisfies the following invariants:

• $Q_s$ is a syntactic and semantic projection of $Q_c$, retaining the dialect feature(s) $d$.
• $Q_s$ executes successfully on $S$, i.e., $\mathit{Exec}_S(Q_s)$ completes without error.
• $Q_s$ reproduces the same dialect error on $T$, i.e., $\mathit{Exec}_T(Q_s)$ raises error message $E_d$ as observed for $Q_c$.

The resultant $Q_s$ thus isolates the dialect-relevant portion needed for robust translation rule inference.

2. Two-Phase Query Reduction Methodology

The reduction proceeds in two algorithmic phases, operating over the abstract syntax tree (AST) of $Q_c$:

Phase I: Syntax-based Random Reduction

• For the AST $\mathrm{AST}(Q_c)$ and error $E_d$, randomly select and tentatively delete up to two non-root subtrees.
• Regenerate the candidate query and evaluate its execution on both $S$ (should succeed) and $T$ (must yield $E_d$).
• Accept subtree removals only if both conditions hold; continue iteration until no further pruning is possible.
• This stochastic search efficiently discards dialect-irrelevant constructs.

Phase II: LLM-guided Reduction

• The partially reduced query serves as a prompt to an LLM: "Simplify the following query so that it still triggers error ‘$E_d$’ on $T$, remove everything else."
• For each LLM candidate, ensure successful execution on $S$ and error similarity on $T$ (using a similarity threshold of $\ge 0.85$).
• Up to five rounds of refinement are performed, stabilizing upon the most minimal query that preserves the error signature and RDBMS semantics.

The process is formalized by the following schematic pseudocode:

function Reduce(Q_c, S, T, E_d): AST0 ← parse(Q_c) # Phase I: random AST‐pruning repeat: for 2 times: pick random subtree t ⊂ AST0 AST1 ← AST0 \ t q1 ← unparse(AST1) if Exec_S(q1) ok ∧ Exec_T(q1).error == E_d: AST0 ← AST1 else: revert deletion until no deletion succeeds # Phase II: LLM‐guided q_curr ← unparse(AST0) for round in 1..5: candidates ← LLM_simplify(q_curr, E_d) for q_i in candidates: if Exec_S(q_i) ok ∧ similarity(Exec_T(q_i).error, E_d) ≥ .85: return q_i return q_curr

3. Automatic Extraction and Abstraction of Translation Rules

Upon obtaining $Q_s$, the LLM (via the existing CoT translator) produces the target-dialect translation $Q_s'$. The ASTs $A_s = \mathrm{AST}(Q_s)$ and $A_s' = \mathrm{AST}(Q_s')$ serve as the basis for rule extraction. The process comprises:

• Initial Rule Extraction: Identify the smallest subtrees $(T_{src}, T_{tgt})$ such that pruning them from $A_s$ and $A_s'$, respectively, results in structurally identical remaining trees.
• Rule Abstraction: Generalize these subtrees into patterns:
  • Substitute non-essential literals and identifiers by placeholders (\$N).
  • Replace new identifiers (e.g., aliases) by ANYVALUE.
  • Use TREE_N wildcards for whole unchanged subtrees.
• Form the rule $$r_d = \langle \mathit{Pat}_{src}, \mathit{Pat}_{tgt} \rangle$$, which matches arbitrary instances of the dialect construct.

4. Application of Translation Rules to Source Queries

Having synthesized the rule $r_d$, the system traverses the original query AST $A_c$. For every matching subtree, placeholders in $\mathit{Pat}_{src}$ are bound and instantiated into the corresponding portion of $\mathit{Pat}_{tgt}$, with ANYVALUE tokens assigned as needed. Each occurrence of the dialect feature is rewritten in situ; the final query, after unparse, represents the complete, context-aware translation.

A canonical example is the transformation of SQL's FULL OUTER JOIN (unsupported in some RDBMSs) into a union of left-joins as identified and generalized through reduction, LLM translation, and rule extraction. The output rule is then replayed systematically over all instances in $Q_c$, yielding $Q_c'$.

5. Empirical Evaluation: Accuracy and Efficiency

Comprehensive benchmarking on TPC-DS and SQLProcBench demonstrates the empirical effectiveness of dialect-aware query reduction within the RISE system. Results are summarized below:

Benchmark	Accuracy of RISE	Best-of-Baseline (System)
TPC-DS	97.98%	90.91% (GPT-LLMTranslator)
SQLProcBench	100.00%	81.82% (DS-LLMTranslator)

Average improvements of 24.62 and 238.41 percentage points over the best traditional rule-based and pure-LLM methods respectively underscore the approach. With a stabilized throughput of 3.78 correct translations per minute post rule-learning (versus 3.30 qpm direct LLM), the approach reveals measurable advantages in both translation accuracy and throughput.

6. Core Implications and Technical Significance

Dialect-aware query reduction:

• Isolates only constructs responsible for dialect errors, eliminating noise and redundancy in LLM translation tasks.
• Dramatically shrinks the token and structural complexity presented to LLMs, mitigating the failure modes associated with direct end-to-end translation of long, complicated queries.
• Enables the system to automatically synthesize compact, repeatable AST rewrite rules, facilitating generalized, scalable application across varied query corpora and RDBMS dialects.
• Eliminates dependence on manual rule authoring and obviates the need to solicit full-query LLM translations repeatedly, enhancing both reliability and reproducibility in cross-dialect SQL migration.

A plausible implication is that these properties position dialect-aware query reduction as an efficient, resource-sensitive stepping stone for combinatorial program translation tasks, especially in domains marked by frequent, subtle syntactic or semantic divergences between programming dialects (Xie et al., 9 Jan 2026).

7. Example Workflow

A summary of the key procedural stages is provided for reference:

Stage	Purpose	Output
Error Detection	Identify dialect feature $d$ failing on target RDBMS $T$	Error message $E_d$
Random AST Reduction	Remove irrelevant query parts while preserving $d$	Initial reduced query $Q_s$
LLM-guided Minimalization	Semantic query simplification preserving error $E_d$	Final reduced query $Q_s$
LLM Translation	Translate $Q_s$ into $Q_s'$ for target dialect	$Q_s'$
Rule Extraction/Abstraction	Isolate, generalize translation pattern ($r_d$)	Pattern pair ($r_d$)
Rule Application	Apply $r_d$ to all matches in original query $Q_c$	Translated query $Q_c'$

This systematic approach assures the conformance, generality, and scalability of SQL dialect translation for RDBMS migration and interoperability scenarios (Xie et al., 9 Jan 2026).