This is probably a bigger discussion, but let me kick it off here anyway.
Some of our planner rules have public constructors with Class arguments, and
therefore people can create their own rule instances that match particular
sub-classes. Other planner rules do not have those public
For #1, can you please give an example?
For #2, I run the calcite UT, and they all passed. Is Durid test part of the
UT? If not, how do I run them? Thanks.
> On Oct 28, 2019, at 7:57 PM, Danny Chan wrote:
>
> Thanks Xiening Dai for bringing up this topic ~
>
> I agree that for most of the
Thanks Xiening Dai for bringing up this topic ~
I agree that for most of the planning rules, only matching logical nodes are
enough. There are 2 concerts from my side:
• We have some plan rewrite that indeed happens on the “physical” node, so some
the rules may be still useful for such case,
; - Haisheng
>
> ----------
> 发件人：Xiening Dai
> 日 期：2019年10月29日 06:13:13
> 收件人：
> 主 题：Re: Same rules fired for logical and physical nodes
>
> I open a PR - https://github.com/apache/calcite/pull/1543
>
>
ementation phase.
[1]
https://www.cse.iitb.ac.in/infolab/Data/Courses/CS632/Papers/Cascades-graefe.pdf
- Haisheng
--
发件人：Xiening Dai
日 期：2019年10月29日 06:13:13
收件人：
主 题：Re: Same rules fired for logical and physical nodes
I open a
I open a PR - https://github.com/apache/calcite/pull/1543
> On Oct 28, 2019, at 3:00 PM, Xiening Dai wrote:
>
> Thanks for you input.
>
> I think this doesn’t relates to the Volcano theory. I don’t try to separate
> the logical transformation from physical implementation. What I propose is
>
Thanks for you input.
I think this doesn’t relates to the Volcano theory. I don’t try to separate the
logical transformation from physical implementation. What I propose is not to
fire the same transformation rule on physical nodes as those transformation are
already done on the logic nodes.
Hello,
It is not surprising that by reducing the scope of the rules the
planning times goes down since we are generating less alternatives.
Mixing logical with physical optimizations is costly but it is one of the
big benefits offered by the Volcano framework in contrast with the System-R
style
Agree, it is indeed redundant. We had a discussion about this in pull request
#1130 [1].
Many of these rules not only match physical operaors, but still generate new
logical operators.
IMHO, rules should match logical operators only.
[1] https://github.com/apache/calcite/pull/1130
On
Hi all,
While I was looking at CALCITE-2970, I noticed that some of the rules are fired
for both logical and physical nodes. For example, ProjectMergeRule matches
Project.class, so it’s fired for LogicalProject. But then after LogicalProject
is converted into EnummerableProject, the same rule
10 matches
Mail list logo
