[jira] [Assigned] (IGNITE-25471) Sql. Introduce custom infrastructure for rel explanation

["Konstantin Orlov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-25471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konstantin Orlov reassigned IGNITE-25471:
-----------------------------------------

    Assignee: Konstantin Orlov

> Sql. Introduce custom infrastructure for rel explanation
> --------------------------------------------------------
>
>                 Key: IGNITE-25471
>                 URL: https://issues.apache.org/jira/browse/IGNITE-25471
>             Project: Ignite
>          Issue Type: Improvement
>          Components: sql ai3
>            Reporter: Konstantin Orlov
>            Assignee: Konstantin Orlov
>            Priority: Major
>              Labels: ignite-3
>
> Currently, we are taking an advantage of {{org.apache.calcite.rel.RelNode#explain(org.apache.calcite.rel.RelWriter)}}. This approach has number of drawbacks.
> First, we don't have necessary control over attributers included into printout. For example,   the output of {{TableModify}} node contains attributes {{sourceExpressionList}} and {{flattened}} which doesn't make sense in our case. This can be WA'ed by inlining all the explainTerms of parent rel within {{IgniteTableModify}}, but there is a chance to break serialization in case new attributes is introduced in upcoming release.
> Second, we are resolving indexes into column names, and sometimes you need to know context to do it properly. For example, {{IgniteMergeJoin}} has {{leftCollation}} and {{rightCollation}} which must be resolved with lhs or rhs row type respectively. The context is available in {{org.apache.ignite.internal.sql.engine.rel.IgniteMergeJoin#explainTerms}}, but is completely lost in relation-agnostic {{RelWriter}}.
> Given that said, it would be beneficial to introduce distinct infrastructure to printout relations for EXPLAIN command.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)