to allow users to create their own sub-class of
> > RelMetadataQuery?
> >
> > - Haisheng
> >
> > ----------
> > 发件人：Julian Hyde
> > 日 期：2019年10月22日 09:58:34
> > 收件人：dev
> > 主 题：Re: [DISCUSSION] Extension o
eate their own sub-class of
> > RelMetadataQuery?
> >
> > - Haisheng
> >
> > ----------
> > 发件人：Julian Hyde
> > 日 期：2019年10月22日 09:58:34
> > 收件人：dev
> > 主 题：Re: [DISCUSSION] Extension of Metadata Q
> Can we create a JIRA to allow users to create their own sub-class of
> RelMetadataQuery?
>
> - Haisheng
>
> --
> 发件人：Julian Hyde
> 日 期：2019年10月22日 09:58:34
> 收件人：dev
> 主 题：Re: [DISCUSSION] Extension o
Sounds like we have reached a consensus, I guess.
Can we create a JIRA to allow users to create their own sub-class of
RelMetadataQuery?
- Haisheng
--
发件人：Julian Hyde
日 期：2019年10月22日 09:58:34
收件人：dev
主 题：Re: [DISCUSSION] Extension
I agree with Danny. We should believe that uses can handle it well.
Best,
Chunwei
On Tue, Oct 22, 2019 at 3:26 PM Danny Chan wrote:
> > I don’t trust the typical Calcite user to be able to write a sub-class
> that works correctly and efficiently.
>
> People who sub-class RelMetadataQuery are
> I don’t trust the typical Calcite user to be able to write a sub-class that
>works correctly and efficiently.
People who sub-class RelMetadataQuery are almost those who has deep
customization of the calcite-core, for example, the MaxCompute or the Apache
Flink.
We may assume that it is not
Yes, the division of labor between MetadataFactory and RelMetadataQuery is a
good one, and we should keep them intact. One provides the raw metadata, and
the other provides a typed interface and transactions/caching.
It might be allowable for a user to create their own sub-class of
+1 on Danny's comment.
If we use MedataFactory to customize and use RelMetadataQuery for
convenience, that will make user confused.
Danny Chan 于2019年10月18日周五 下午12:33写道：
> That is the point, we should supply a way to extend the RelMetadataQuery
> conveniently for Calcite, because in most of the
That is the point, we should supply a way to extend the RelMetadataQuery
conveniently for Calcite, because in most of the RelOptRules, user would use
the code like:
RelOptRuleCall.getMetadataQuery
To get a RMQ instead of using AbstractRelNode.metadata() to fetch a
MedataFactory.
We should at
RelMetadataQuery as the way to add costomized metadata, deprecating
MetadataFactory is not a wise choice.
- Haisheng
--
发件人：XING JIN
日 期：2019年10月17日 15:55:31
收件人：
主 题：Re: [DISCUSSION] Extension of Metadata Query
BTW, I think one
At least in our project (Apache Ignite) we use AbstractRelNode.metadata().
But it so because there is no way to put our metadata type into
RelMetadataQuery without changes in Calcite.
Regards,
Igor
чт, 17 окт. 2019 г., 19:16 Xiening Dai :
> MetadataFactory is still useful. It provides a way to
MetadataFactory is still useful. It provides a way to access Metadata directly.
If someone creates a new type of Metadata class, it can be accessed through
AbstractRelNode.metadata(). This way you don’t need to update RelMetadataQuery
interface to include the getter for this new meta. Although
BTW, I think one JIRA number discussed in the thread would be
https://issues.apache.org/jira/browse/CALCITE-2855 not CALCITE-2885
Best,
Jin
XING JIN 于2019年10月17日周四 下午3:49写道：
> 1. RelMetadataQuery covers the functionality of MetadataFactory, why
> should we keep/maintain both of them ? shall we
1. RelMetadataQuery covers the functionality of MetadataFactory, why should
we keep/maintain both of them ? shall we just deprecate MetadataFactory. I
see MetadataFactory is rarely used in current code. Also I
think MetadataFactory is not good place to offering customized metadata,
which will make
I have seen both patterns in current code base. In most places, for example
SubQueryRemoveRule, AggregateUnionTrasposeRule SortJoinTransposeRule, etc.,
RelOptCluster.getMetadataQuery() is used. And there are a few other places
where new RelMetadataQuery instance is created, which Haisheng
This is the reason I was struggling for the discussion.
Best,
Danny Chan
在 2019年10月16日 +0800 AM11:23，dev@calcite.apache.org，写道：
>
> RelMetadataQuery
: [DISCUSSION] Extension of Metadata Query
Yes, but why RelOptCluster? Besides the fact that there happened to be a method
there.
> On Oct 15, 2019, at 7:30 PM, Haisheng Yuan wrote:
>
> > Is there a good rationale for attaching one to RelOptCluster
> Customized RelMetadataQuery with
for customized
> metadata, also can provide convenient way to get metadata.
>
> - Haisheng
>
> --
> 发件人：Julian Hyde
> 日 期：2019年10月16日 06:52:39
> 收件人：
> 主 题：Re: [DISCUSSION] Extension of Metadata Query
>
>
日 期：2019年10月16日 06:52:39
收件人：
主 题：Re: [DISCUSSION] Extension of Metadata Query
Having reviewed https://issues.apache.org/jira/browse/CALCITE-3403
<https://issues.apache.org/jira/browse/CALCITE-3403> and
https://issues.apache.org/jira/browse/CALCITE-2018
<https://issues.apache.org
ractice? If not, any other better approach to suggest?
> Thanks.
> Haisheng
>
> ------
> 发件人：Stamatis Zampetakis
> 日 期：2019年06月15日 15:47:58
> 收件人：
> 主 题：Re: [DISCUSSION] Extension of Metadata Query
>
> I h
.
Haisheng
--
发件人：Stamatis Zampetakis
日 期：2019年06月15日 15:47:58
收件人：
主 题：Re: [DISCUSSION] Extension of Metadata Query
I had a look on CALCITE-1147 (which added support for custom providers and
metadata) and based on the added tests [1
I had a look on CALCITE-1147 (which added support for custom providers and
metadata) and based on the added tests [1], it seems that the main
alternative to RelMetadataQuery is indeed through the MetadataFactory. One
other alternative I can think of, is to pass a custom RelMetadataQuery (or
a
We have an interface to fetch the RelMetadataQuery in RelOptRuleCall [1], which
I believe is the most common routine to query metadata during planning, I’m a
little confused for your saying
>The methods in RelMetadataQuery are for convenience only.
If these methods in RelMetadataQuery are only
The goal is that it should be possible to add a new kind of metadata. The
methods in RelMetadataQuery are for convenience only. So you should be able to
use your new kind of metadata, and existing ones, without modifying
RelMetadataQuery.
If that is not possible, it’s a bug, and you should log
Thanks, Stamatis
You are right, this discussion came up due to CALCITE-2885, it is not about the
performance problem, it is the extension of RelMetadataQuery, because we add
all kinds of top interfaces in RelMetadataQuery, e.g. the row count query [1].
When we add a new RelMetadataProvider, a
In order to add some top-level query interfaces like columnInterval to topK,
one way to extend the RelMetadataQuery is “sub-class” it, but a
subclass-instance of RelMetadataQuery can not be set into the
RelOptCluster(with a always default singleton RMQ instance), which is a key
factor to
By “extend” do you mean “sub-class”?
> On Jun 4, 2019, at 10:19 PM, Yuzhao Chen wrote:
>
> Thanks Julian for your detail reply,
>
>
> 1. I checked the Janino gened-code and the
> RelMetadataQuery/RelMetadataProvidor and almost can make sure MetadataQuery
> only use the
Thanks Julian for your detail reply,
1. I checked the Janino gened-code and the RelMetadataQuery/RelMetadataProvidor
and almost can make sure MetadataQuery only use the
RelMetadataProvidor#handlers method for multiple dispatch, the
RelMetadataProvidor#apply is only used for MetadataFactory.
Thanks for raising this, Danny. Actually I have the same question too.
> RelMetadataQuery is not an extension point. Its sole purpose is to to
keep state (the cache and cycle-checking)
I think users may extend the RelMetadataQuery if wanting to query more
metadata, such as TopK values.
Best,
Thanks for bringing this up Danny.
I guess the discussion came up due to CALCITE-2885 [1]. Looking back into
it, I am not sure that the intention there is to make the RelMetadataQuery
pluggable. We could possibly solve the performance problem without
extending the RelMetadataQuery. We have to
> 1. Why we have 2 methods in RelMetadataProvider?
The metadata system is complicated. We need to allow multiple handlers
for any given call. So, making a metadata call involves multiple
dispatch [1] based on the metadata method being called, the type of
RelNode, and the handlers that are
Currently we provide answer to metadata query through RelMetadataProvider [1],
there are some sub-classes of it:
RelMetadataProvider
|
|- VolcanoRelMetadataProvider
|- ChainedRelMetadataProvider/DefaultRelMetadataProvider
|- HepRelMetadataProvider
|- CachingRelMetadataProvider
|-
32 matches
Mail list logo
