ain/java/devozerov/HazelcastConventions.java#L44
> > >>
> > >> Try this:
> > >>
> > >> fromTraits.containsIfApplicable(Convention.PHYSICAL)
> > >> && toTraits.containsIfApplicable(Convention.PHYSICAL);
> > >>
>
AL)
> >> && toTraits.containsIfApplicable(Convention.PHYSICAL);
> >>
> >>
> >> Adding a AbstractConverter on logical operators is meaningless. Calcite
> >> is mixing the concept of logical and physical together, which is sad.
> >>
> >>
,
>>>
>>> This is still can be done through top-down request approach.
>>>
>>> PhysicalFilter operator should request ANY distribution from child
>>> operator, unless there is outer reference in the filter condition, in which
>>> case, PhysicalF
> 发件人：Vladimir Ozerov
> 日 期：2019年11月05日 18:02:15
> 收件人：Haisheng Yuan
> 抄 送：dev@calcite.apache.org (dev@calcite.apache.org) >
> 主 题：Re: Re: Problem with converters and possibly rule matching
>
> Hi Haisheng,
>
> think I already tried something very similar
Haisheng
--
发件人：Vladimir Ozerov
日 期：2019年11月05日 18:02:15
收件人：Haisheng Yuan
抄 送：dev@calcite.apache.org (dev@calcite.apache.org)
主 题：Re: Re: Problem with converters and possibly rule matching
Hi Haisheng,
think I already tried something very similar to what you explained, but
rule.
> Note that IndexGet is a logical operator and IndexScan is a physical
> operator, which are also used by SQL Server.
>
> - Haisheng
>
> --
> 发件人：Vladimir Ozerov
> 日 期：2019年11月01日 17:30:26
> 收件人：
> 主 题：Re: Problem with converters and possibly ru
Scan physical implementation rule.
> Note that IndexGet is a logical operator and IndexScan is a physical
> operator, which are also used by SQL Server.
>
> - Haisheng
>
> --
> 发件人：Vladimir Ozerov
> 日 期：2019年11月01日 1
and IndexScan is a physical operator,
which are also used by SQL Server.
- Haisheng
--
发件人：Vladimir Ozerov
日 期：2019年11月01日 17:30:26
收件人：
主 题：Re: Problem with converters and possibly rule matching
Hi Stamatis,
Thank you for your
Hi Stamatis,
Thank you for your reply. I also thought that we may set the distribution
trait during logical planning because it is known in advance. And the
example I gave will work! :-) But unfortunately, it will work only because
the tree is very simple, and the Project is adjacent to the Scan.
Stamatis,
Small comment from me, for distributed systems is more efficient if
SINGLETON distribution appears only on root node, in other words as late as
possible, it allows to filter or cut rows (project) on source nodes which
significantly reduces network costs.
To do that (In case we use
The discussion is interesting thanks for the nice examples.
I am replying in this thread since it has all the examples and the history
of the conversation.
*Part I: Distribution physical or logical property*
The Volcano paper writes the following regarding properties:
"Logical properties can be
Hi Stamatis,
The problem that the presented reproducer is a very simplified version of
what is actually needed. In reality, there are several distribution types -
PARTITIONED, REPLICATED, SINGLETON. To make things worse, PARTITIONED may
or may not have concrete distribution fields. In theory, I
I admit that I didn't thoroughly read the exchanges so far but forcing the
rules trigger does not seem the right approach.
Other than that I would like to backtrack a bit to point 4.3 raised by
Vladimir.
"ProjectPhysicalRule [6] - transforms logical project to physical
project *ONLY* if there is
Unfortunately it requires package-private API usage.
Best solution there if Calcite provide it for end users.
ср, 30 окт. 2019 г., 18:48 Vladimir Ozerov :
> “e pension” == “expand conversion” :)
>
> ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :
>
> > Yes, that may work. Even if e pension rule
Yes, that may work. Even if e pension rule is used, for the most cases it
will not trigger any real conversions, since we are moving from abstract
convention to physical, and created converters will have the opposite trait
direction (from physical to abstract).
But again - ideally we only need to
“e pension” == “expand conversion” :)
ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :
> Yes, that may work. Even if e pension rule is used, for the most cases it
> will not trigger any real conversions, since we are moving from abstract
> convention to physical, and created converters will have
I considered manual rules calling too, for now we use abstract converters +
ExpandConversionRule for exchanges producing.
You may create such converters manually (checking appropriate subset) this
case you may reduce created converters count, also, a converter is a quite
special node, that does
One funny hack which helped me is manual registration of a fake RelNode
with desired traits through VolcanoPlanner.register() method. But again,
this leads to trashing. What could really help is a call to
VolcanoPlanner.fireRules() with desired rel. But this doesn't work out of
the box since some
Hi Igor,
Yes, I came to the same conclusion, thank you. This is how it basically
happens when converters are disabled:
1) We start with initial tree: [LogicalProject] <- [LogicalScan]
2) Then we convert LogicalScan to PhysicalScan, so it is added to the
set: [LogicalProject]
<- [LogicalScan,
Vladimir,
Probably it'll help you:
Seems the cause of issue in RelSubset.getParentRels() The check used when
the planner schedules newly matched rules after successful transformation
(see VolcanoRuleCall.matchRecurse), it prevents the parent rule be applied
once again (here your logical project
Hi Vladimir,
I am sorry. Pushed, it works now.
вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov :
> > mvn clean test
>
> [ERROR] The goal you specified requires a project to execute but there is
> no POM in this directory
>
> Vladimir, please push missing files
>
> Vladimir
>
> mvn clean test
[ERROR] The goal you specified requires a project to execute but there is
no POM in this directory
Vladimir, please push missing files
Vladimir
Hi colleagues,
I prepared (relatively) simple reproducer for the problem [1]. It can be
executed with three commands:
git clone https://github.com/devozerov/calcite-optimizer.git
cd calcite-optimizer
mvn clean test
Please do not pay attention to stuff located inside "org.apache.calcite"
package,
Hi everybody,
First of all, thank you for answers and suggestions. Let me address them
briefly:
1) I use two conventions at the moment, LOGICAL and PHYSICAL. I agree with
you that this might be overkill, and there is a chance that in the final
solution we may end up with only one. But meanwhile
Vladimir,
I guess Project rule doesn't have a child matcher. Put into it child "any"
match rule and it will apply on each child node transformation.
Regards,
Igor
вт, 29 окт. 2019 г., 7:07 Danny Chan :
> Vladimir, all you need to do is to change the convention of the root node,
> the volcano
Vladimir, all you need to do is to change the convention of the root node, the
volcano would propagate the convention to all its input nodes when registering
them to the planner. You can take this code [1] for reference :)
[1]
.
- Haisheng
--
发件人：Stamatis Zampetakis
日 期：2019年10月29日 06:10:45
收件人：
主 题：Re: Problem with converters and possibly rule matching
Hi Vladimir,
You can get an idea of how the Volcano planner works by reading [1].
The implementation of the Volcano in Calcite has many differences
Hi Vladimir,
You can get an idea of how the Volcano planner works by reading [1].
The implementation of the Volcano in Calcite has many differences but the
main ideas are there.
Normally you do not need to set canConvertConvention to true; especially in
your case it doesn't seem necessary.
I
28 matches
Mail list logo
