Fine-tune LLMs with execution plans and RL to rewrite SQL that runs faster while staying correct.

August 12, 20258 min

Overview

Production Readiness

0.7

Novelty Score

0.65

Cost Impact Score

0.7

Citation Count

0

Authors

Dongjie Xu, Yue Cui, Weijie Shi, Qingzhi Ma, Hanghui Guo, Jiaming Li, Yao Zhao, Ruiyuan Zhang, Shimin Di, Jia Zhu, Kai Zheng, Jiajie Xu

Links

Abstract / PDF

Why It Matters For Business

E3-Rewrite can cut query costs by reducing runtime for heavy analytical queries while keeping results correct. That directly lowers compute bills and improves interactive analytics latency for complex queries.

Summary TLDR

E3-Rewrite fine-tunes large language models with execution-aware prompts and reinforcement learning to produce SQL rewrites that are executable, semantically equivalent, and faster. Key ingredients: prepend EXPLAIN plan text to prompts, retrieve similar successful rewrites, and train with a two-stage RL curriculum that first enforces correctness then optimizes latency.

Problem Statement

Rule-based SQL rewriting is brittle and hard to extend. LLMs can express richer rewrites but often produce non-executable or non-equivalent SQL and can hurt performance. We need a learnable system that reliably generates executable, equivalent, and faster SQL.

Main Contribution

E3-Rewrite: end-to-end LLM-based SQL rewriting that optimizes for executability, equivalence, and efficiency without hand-coded rules.

Execution-hint prompts: prepend linearized EXPLAIN / EXPLAIN ANALYZE plans so the model sees operator choices and bottlenecks.

Two-stage RL (GRPO) curriculum: stage 1 enforces executability and equivalence; stage 2 adds a performance reward to reduce latency.

Hybrid demonstration retrieval: retrieve past high-quality rewrite pairs by structural (AST) and semantic similarity and update the pool online.

Key Findings

Big average latency reduction on TPC-H.

NumbersAvg latency 78.81s -> 29.67s (Original vs E3-Rewrite Qwen, Table 1)

High correctness while improving many queries.

Numbers210 improved queries and 99.6% equivalence on TPC-H (Qwen 32B, Table 2)

Reinforcement learning is essential for equivalence.

NumbersEquivalence 99.6% (full) -> 90.1% (w/o RL, Table 4)

Execution-plan hints materially reduce latency.

NumbersAvg latency 29.67s (full) -> 39.56s (w/o plan hints, Table 4)

Results

TPC-H average latency (Original)

Value78.81s

TPC-H p90 latency

Value300.00s (Original)

Improved queries (>=10% speedup)

Value210

Equivalence ratio after rewriting

Value99.6%

Ablation: equivalence without RL

Value90.1%

Baseline99.6% (full)

Ablation: effect of removing execution plan hints on avg latency

Value39.56s (w/o hints)

Baseline29.67s (full)

Who Should Care

What To Try In 7 Days

Run EXPLAIN for a few slow, important queries and prepend the plan text to an LLM prompt to see whether simple plan-aware edits help.

Collect a small demo pool of original+good-rewrite pairs and try retrieval-based prompting to reuse patterns.

Add a post-check that compares outputs between original and rewritten queries on sample DB instances before deploying rewrites.

Agent Features

Memory

  • dynamic demonstration pool (online updates of rewrite pairs)

Planning

  • curriculum: correctness → performance

Tool Use

  • uses EXPLAIN / EXPLAIN ANALYZE as external tool
  • uses QEDsolver for formal equivalence checks

Frameworks

  • GRPO

Architectures

  • GRPO
  • two-stage curriculum learning

Optimization Features

Training Optimization

  • GRPO
  • curriculum-guided two-stage training
  • rehearsal of Stage 1 examples during Stage 2

Inference Optimization

  • prepend linearized execution plans to prompts
  • retrieve top-k hybrid demonstrations (structure + semantics)

Reproducibility

Data Urls

  • TPC-H (public)
  • IMDB / JOB (public)
  • DSB (public)

Data Available

Open Source Status

  • partial

Risks & Boundaries

Limitations

  • Experiments run on PostgreSQL v14; optimizer behavior may differ across DBMSs.
  • Equivalence checking relies on QEDsolver + LLM fallbacks; solver timeouts force heuristic decisions.
  • Estimated cost from EXPLAIN (optimizer estimates) can diverge from real runtime, causing imperfect perf signals.
  • Closed-source LLM baselines (GPT-4o) limit head-to-head reproducibility for some comparisons.

When Not To Use

  • When formal proof of semantic equivalence is mandatory and solver support is required for all constructs.
  • On DBMSs that do not expose comparable EXPLAIN plans or have very different optimizer IDs.
  • For trivial, short queries where rule-based fixes are simpler and cheaper.

Failure Modes

  • LLM generates syntactically valid but semantically different SQL; fallback checks may be inconclusive.
  • Optimizer cost estimates mislead the performance reward, causing rewrites that appear better to EXPLAIN but worsen real latency.
  • Demonstration pool contamination: adding low-quality rewrites could bias retrieval and outputs.

Core Entities

Models

  • Qwen (Qwen 14B)
  • Qwen (Qwen 32B)
  • LLaMA4
  • GPT-4o

Metrics

  • Query Latency
  • Equivalence Ratio
  • Improved Queries (>=10% speedup)

Datasets

  • TPC-H
  • IMDB (JOB)
  • DSB

Benchmarks

  • TPC-H
  • IMDB (JOB)
  • DSB