[
https://issues.apache.org/jira/browse/CALCITE-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047854#comment-18047854
]
Zhen Chen commented on CALCITE-7342:
------------------------------------
I'm not sure if now is a good time to merge this PR. During the gradual process
of adding back the removed files, we will need two types of decorrelators. The
new decorrelation plan needs to be wrapped in
"!if(enable_general_decorrelator)", while the old decorrelation plan needs to
be wrapped in
"!if(disable_general_decorrelator)". It is possible that those familiar with
the old decorrelation will always use
"!if(disable_general_decorrelator)", and vice versa, those familiar with the
new decorrelation will always use
"!if(disable_general_decorrelator)". This will continue to create
discrepancies. Regardless, the coexistence of the two will involve a long
transition period, or they may even coexist indefinitely. I wanted to raise
this issue. If most agree to merge, I will proceed. Alternatively, if there are
better solutions, they are also welcome.
> Quidem test support for TopDownGeneralDecorrelator
> --------------------------------------------------
>
> Key: CALCITE-7342
> URL: https://issues.apache.org/jira/browse/CALCITE-7342
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.41.0
> Reporter: Zhen Chen
> Assignee: Zhen Chen
> Priority: Minor
> Labels: pull-request-available
>
> We recently merged the new TopDownGeneralDecorrelator (CALCITE-7031).
> Currently, configuration has only been added to RelOptFixture, but end-to-end
> testing of Calcite cannot be performed using the new Decorrelator. To perform
> end-to-end testing, we might need a configuration to enable the new
> Decorrelator (it's disabled by default). This is necessary to advance the
> further development and validation of the new Decorrelator, such as
> implementing MARK JOIN in CALCITE-7315 in the future, or assuming the new
> Decorrelator can truly become a production-ready option for users. All of
> this requires thorough testing, so this Jira implementation aims to provide a
> quidem test example that supports the new Decorrelator to support future
> development. However, this will introduce a configuration parameter to enable
> the new Decorrelator, which may remain for a considerable period until the
> new Decorrelator reaches production-ready status.
> The current Jira idea is to provide a dedicated decorrelate.iq file to
> support continuous iteration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
