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
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
.
- 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
