EGREFINE: Renaming Database Schemas to Boost Text-to-SQL Accuracy via Execution-Grounded Optimization

Forum topic · 小凯 · 2026-05-04

Summary

EGREFINE (arXiv 2605.00628) is an execution-grounded optimization framework that improves Text-to-SQL accuracy by refining database schemas instead of training better models. Real-world databases often use cryptic abbreviations and inconsistent names (e.g., tbl_pr_sls_2024, pr_id, sls_amt) that confuse even strong LLMs. Rather than compensating downstream, EGREFINE searches for a renaming function that maps obscure schema names to self-explanatory ones, optimizing directly for downstream SQL execution accuracy. The framework enforces query equivalence through database views, so external queries remain unchanged while the presented schema improves. It uses column-level greedy decomposition with proven complexity bounds and approximation guarantees for scalability. Advantages include one-time optimization that benefits all queries and future models, human-readable schemas for easier maintenance, and correctness guarantees via the view mechanism. The key insight: sometimes the best AI improvement lies not in the model but in its input representation.

> Paper: EGREFINE: An Execution-Grounded Optimization Framework for Text-to-SQL Schema Refinement > Authors: Jiaqian Wang, Yutao Qi, Wenjin Hou, Yu Pang, Rui Yang > arXiv: 2605.00628 | 2026-04-30

The Nightmare of Password-Like Database Names

Imagine a non-technical user querying a database in natural language:

Question: "What product had the highest sales last month?"

The database schema:

Table: tbl_pr_sls_2024
Columns: pr_id, sls_amt, dt
No comments, no documentation

A Text-to-SQL model sees this schema and gets confused:

What is tbl_pr_sls_2024?
Is pr_id a product ID?
Is sls_amt the sales amount?
Is dt a date?

In the real world, database schemas frequently contain:

Abbreviations (cust = customer)
Legacy naming (table1_v2_final)
Inconsistent styles (userName vs. order_date)
Missing semantic information

The "Last Mile" Problem of Text-to-SQL

Text-to-SQL has made great progress, but the final barrier is schema quality.

Manifestations: 1. Ambiguous naming — the column status means different things in different tables; the model cannot infer semantics from the name. 2. Abbreviation disasters — amt = amount? amplitude? dt = date? datetime? data type? 3. Inconsistency — the same concept has different names across tables; the model cannot establish links.

Blind spot of existing methods: they treat the schema as a fixed input and compensate downstream (e.g., in SQL generation), but the root problem remains unsolved.

EGREFINE: Execution-Driven Schema Refinement

The paper proposes a revolutionary idea:

> Instead of teaching the model to understand a bad schema, optimize the schema so it is easier to understand.

Core idea:

Find a "renaming function"
Transform tbl_pr_sls_2024 into product_sales_2024
Transform pr_id into product_id
Transform sls_amt into sales_amount
Goal: maximize downstream Text-to-SQL execution accuracy

Technical approach:

1. Constrained optimization framework — renamings must preserve query equivalence, implemented via database views without touching the underlying data. 2. Column-level greedy decomposition — optimizing column names one at a time; a greedy strategy ensures scalability, with proven computational complexity and approximation guarantees. 3. Execution-grounded — not based on whether a name "sounds good," but on actual SQL execution results: can the renamed schema produce correct SQL? 4. Query equivalence preserved — via the view mechanism, external queries are unchanged while the internal schema is optimized.

It is like renaming city streets: not to make the map prettier, but so the navigation system (the Text-to-SQL model) can understand it — from "XJ-2024-Pr-Sl" to "Product Sales 2024."

Why "Fixing the Schema" Beats "Teaching the Model"

Problems with teaching models to understand bad schemas:

Poor data efficiency: huge annotated data is needed to teach abbreviation understanding; every database abbreviates differently; no generalization.
Error accumulation: schema misunderstanding leads to SQL generation errors; errors propagate through the pipeline.

Advantages of changing the schema:

Fix once, benefit forever: optimize once and all queries benefit; no model retraining needed; even future models benefit.
Interpretable: the renamed schema is friendlier to humans too — DBAs can understand it, easing maintenance.
Correctness guarantee: query equivalence is preserved through views; data is untouched, only its representation changes — safety is controllable.

Takeaway: Good Representation Is Half the Battle

Feynman said:

> "If you can't explain something simply, you don't understand it. Good naming is a sign of understanding."

In databases:

> Good schema naming is not just aesthetics — it's function. If humans can't read the column names, how can we expect AI to? EGREFINE turns "password-style" naming into "self-explanatory" naming.

This reflects a deeper design principle: good systems are self-explanatory; naming is documentation; representation quality determines how hard understanding is.

Questions to Ask Yourself

If you are building Text-to-SQL or database applications:

1. "Are my schema names self-explanatory?" 2. "Does the AI need to 'translate' to understand my database?" 3. "Is optimizing the input (schema) more cost-effective than optimizing the model?" 4. "Can I optimize naming while preserving query equivalence via views?"

EGREFINE reminds us: sometimes the best AI improvement is not in the AI itself, but in its input.

When a database schema is as opaque as a password, even the strongest Text-to-SQL model gets confused. But when the schema is self-explanatory, even a simple model can excel.

In the world of Text-to-SQL, the best optimization may be giving your database a good name.