EGREFINE: An Execution-Grounded Optimization Framework for Text-to-SQL Schema Refinement

> 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

1. The Nightmare of Password-Like Database Names

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

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

But the schema looks like this:

• 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 are often full of:

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

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

Text-to-SQL has made great progress, but a final barrier remains: schema quality.

Problem manifestations: 1. Ambiguous naming — a column named status means different things in different tables; the model cannot infer semantics from the name. 2. Abbreviation disasters — is amt amount? amplitude? Is dt date? datetime? data type? 3. Inconsistency — the same concept has different names in different tables; the model cannot build associations.

Blind spot of existing methods: they treat the schema as fixed input and compensate downstream (e.g., during SQL generation), but never fix the problem at its source.

3. EGREFINE: Execution-Driven Schema Optimization

The paper proposes a revolutionary idea:

> Don't teach the model to understand a bad schema — optimize the schema so it is easier to understand.

Core idea:

• Learn a "renaming function"
• Turn tbl_pr_sls_2024 into product_sales_2024
• Turn pr_id into product_id
• Turn sls_amt into sales_amount
• Objective: maximize downstream Text-to-SQL execution accuracy

Technical approach:

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

It's like renaming the streets of a city — not to make the map prettier, but so navigation systems (Text-to-SQL models) can understand it: from "XJ-2024-Pr-Sl" to "Product Sales 2024."

4. Why "Fix the Schema" Beats "Teach the Model"

Problems with teaching models to understand bad schemas:

• Poor data efficiency: huge labeled data is needed to teach models each database's abbreviations — and they don't generalize.
• Error accumulation: schema misunderstanding → SQL generation errors, propagating through the pipeline.

Advantages of fixing the schema:

• One-time fix, lasting benefit: optimize once and all queries benefit; no model retraining needed; future models benefit too.
• Interpretable: the renamed schema is friendlier to humans and DBAs, easing maintenance.
• Correctness guarantees: the view mechanism preserves query equivalence — only the representation changes, not the data, so safety is controlled.

5. Good Representation Is Half the Battle

As Feynman reportedly 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 isn't just aesthetics — it's function. If even humans can't read the column names, how can we expect AI to? What EGREFINE does is turn password-style names into self-explanatory ones."

This reflects deeper design principles:

• Good systems are self-explanatory
• Naming is documentation
• Representation quality determines how hard understanding is

6. Takeaways

If you're building Text-to-SQL or database applications, ask yourself:

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 use views to preserve query equivalence while improving names?"

EGREFINE reminds us: sometimes the best AI improvement isn't in the AI itself, but in the AI's input.

When a database schema is as cryptic as a password, even the strongest Text-to-SQL model gets confused. But when the schema is self-explanatory, even simple models can excel. In the world of Text-to-SQL, the best optimization may simply be giving your database a better name.