[
https://issues.apache.org/jira/browse/CALCITE-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035755#comment-18035755
]
weihua zhang edited comment on CALCITE-7031 at 11/6/25 8:11 AM:
----------------------------------------------------------------
I agree with [~suibianwanwan33] [~zabetak] .
In my opinion, the new framework and the existing one have similar
capabilities—there are just some scenarios that the existing framework hasn’t
addressed yet. I believe a more cost-effective approach is to supplement the
missing parts of the existing framework with reference to the paper. I think
[~suibianwanwan33] has set a great example in this regard.
[~dongsl]
The existing framework is actually capable of handling subqueries related to
set operations—it just hasn’t been implemented yet. I’ve created CALCITE-7272
to track this issue. According to [~suibianwanwan33], supporting set operations
within the existing framework is straightforward. If you’re interested in
addressing this problem, feel free to give it a try—I’m confident you can
resolve it quickly. A similar issue is CALCITE-7257.
After you fix some bugs in the existing framework, if you find that it indeed
has significant bottlenecks. At that point, your refactoring will become much
more acceptable and convincing.
was (Author: JIRAUSER307426):
I agree with [~suibianwanwan33] [~zabetak] .
In my opinion, the new framework and the existing one have similar
capabilities—there are just some scenarios that the existing framework hasn’t
addressed yet. I believe a more cost-effective approach is to supplement the
missing parts of the existing framework with reference to the paper. I think
[~suibianwanwan33] has set a great example in this regard.
[~dongsl]
The existing framework is actually capable of handling subqueries related to
set operations—it just hasn’t been implemented yet. I’ve created CALCITE-7272
to track this issue. According to [~suibianwanwan33], supporting set operations
within the existing framework is straightforward. If you’re interested in
addressing this problem, feel free to give it a try—I’m confident you can
resolve it quickly. A similar issue is CALCITE-7257.
After you fix some bugs in the existing framework, if you find that it indeed
has significant bottlenecks, you will have a deeper understanding of both the
old and new frameworks. At that point, your refactoring will become much more
acceptable and convincing.
> Implement the general decorrelation algorithm (Neumann & Kemper)
> ----------------------------------------------------------------
>
> Key: CALCITE-7031
> URL: https://issues.apache.org/jira/browse/CALCITE-7031
> Project: Calcite
> Issue Type: Wish
> Components: core
> Affects Versions: 1.39.0
> Reporter: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
>
> Today Calcite uses a heuristic decorrelator which looks for some specific
> patterns and replaces them with equivalent ones. This can handle a restricted
> set of queries.
> There is a general algorithm for doing this, at least for the standard
> operators:
> https://github.com/lonng/db-papers/blob/main/papers/nested-query/unnesting-arbitrary-queries.pdf
> The algorithm is a series of rewrites rules, each of which pushes the
> decorrelation operators down in the plan towards leaves, until they can be
> eliminated.
> It would be great if Calcite had an implementation of this algorithm. This
> could be contributed in pieces, where each rewrite rule is a separate PR. I
> think these rules could be easily implemented in the existing planner rewrite
> framework.
> There are three design problems that I can foresee:
> 1) The plans generated by this algorithm are in general DAGs and not trees. I
> think trees would work, but they have the potential to be much larger than
> the corresponding DAGs (perhaps exponentially larger in the size of the
> original plan). I understand that there is a Calcite operator for
> representing DAGs; I don't know if that's the goal of the Spool operator - it
> seems to imply some kind of materialization of the result. The most important
> decision is how to represent DAG plans such that the rewriting framework
> continues to operate correctly.
> 2) A second issue is that the rewrite rules in the paper use a restricted
> form of relation D which has some nice properties (e.g., it is a set). I am
> not sure how such information can be represented in a Calcite plan, but I
> suspect this can be done.
> 3) Third, while the algorithm in the paper handles many SQL-like operators,
> the Calcite IR is even richer, supporting operators like Window, Cubes,
> Unnest, recursive queries, etc. I don't know how the algorithm would extend
> to plans containing such operators. But even if it doesn't handle all such
> operators, a general-purpose decorrelator would be a significant improvement
> over the existing one.
> This project would also give us the chance to close many issues related to
> the current decorrelator, some of which have been unsolved over many years.
> Please comment here if you are interested in this project. I think the most
> important problem to address is no 1 above, the handling of DAGs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
