Overview
Results use public benchmarks and multiple ablations. Evidence is strong on PostgreSQL v14 and selected workloads, but system and optimizer differences may affect real deployments.
Citations0
Evidence Strength0.80
Confidence0.80
Risk Signals10
Trust Signals
Findings with numeric evidence: 4/4
Findings with evidence refs: 4/4
Results with explicit delta: 6/6
Reproducibility
Status: Partial assets available
Open source: Partial
At A Glance
Cost impact: 70%
Production readiness: 70%
Novelty: 65%
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.
Who Should Care
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.
Key Findings
Big average latency reduction on TPC-H.
High correctness while improving many queries.
Results
| Metric | Value | Baseline | Delta | Split / Dataset | Evidence | Evidence Ref |
|---|---|---|---|---|---|---|
| TPC-H average latency (Original) | 78.81s | — | -> 29.67s with E3-Rewrite (Qwen) | TPC-H (10GB) | Table 1: Original vs E3-Rewrite (Qwen) | Table 1 |
| TPC-H p90 latency | 300.00s (Original) | — | -> 51.37s with E3-Rewrite (Qwen) | TPC-H (10GB) | Table 1 p90 | Table 1 |
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
Planning
Tool Use
Frameworks
Architectures
Optimization Features
Training Optimization
Inference Optimization
Reproducibility
Data URLs
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.
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.
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.