Preserving column names through the optimization process, and many rewrite 
rules being applied, is very hard if not impossible. 

Instead I would approach this as the RelToSqlConverter does, and try to produce 
the best/most concise/most human-readable SQL possible given a RelRoot. 
Flattening the subquery that is generated to project/rename the output columns 
of a Sort seems a reasonable thing to do for RelToSqlConverter to do. My 
approach would be to write a unit test and torture the code until it passes. :) 

> On Jun 25, 2025, at 3:07 AM, Yanjing Wang <zhuangzixiao...@gmail.com> wrote:
> 
> Hi all, I'd like to discuss a challenge regarding the preservation of
> column aliases after RelNode optimization in Apache Calcite. Let me outline
> the specific problem and potential approaches. Problem Statement:
> Currently, when applying RelNode optimization rules, Calcite doesn't
> preserve the original output column aliases. While using RelRoot seems like
> a potential solution, it introduces complications when the optimal RelNode
> is a Sort or similar node. Consider this scenario with a best rel: ` SELECT
> column1, ... FROM ... ORDER BY column1 DESC ` If we try to preserve aliases
> using RelRoot, it might generate SQL like: ` SELECT column1 AS alias1, ...
> FROM ( SELECT ... ORDER BY column1 DESC ) t1 ` This transformation can
> break the ORDER BY clause functionality in many compute engines. Questions
> for Discussion: 1. Is there an existing mature solution in Calcite for
> maintaining output alias consistency after optimization? 2. If not, what
> would be the recommended approach when dealing with Sort nodes (or similar
> RelNodes) that could be affected by RelRoot-based alias preservation? 3. If
> we implement a new solution, should we introduce additional RelOptRules to
> optimize the resulting RelNode structure? This would ensure we maintain
> both alias consistency and query performance.
> I'd appreciate your thoughts and suggestions on this matter, especially
> from those who have encountered similar challenges. Best regards, Yanjing
> Wang

Reply via email to