Hello Pranav,
If you just need to "override" the cost function of certain operators,
there is no need to create new operators (and rules), you can do that by
extending the Metadata.
Let's say you want to override the cost of the Correlate, you should be
able to do that by creating your own class:
public final class YourRelMdNonCumulativeCost implements
MetadataHandler<NonCumulativeCost>
{
static final RelMetadataProvider INSTANCE =
ReflectiveRelMetadataProvider.reflectiveSource(new
YourRelMdNonCumulativeCost(),
BuiltInMetadata.NonCumulativeCost.Handler.class);
private YourRelMdNonCumulativeCost() { }
@Override
public MetadataDef<NonCumulativeCost> getDef() { return
NonCumulativeCost.DEF; }
public RelOptCost getNonCumulativeCost(Correlate correlate,
RelMetadataQuery mq)
{
// your code here...
}
}
And then as MetadataProvider, instead of using just Calcite's default one,
you would use a chain of yours + Calcite's default:
ChainedRelMetadataProvider.of(ImmutableList.of(YourRelMdNonCumulativeCost.INSTANCE,
DefaultRelMetadataProvider.INSTANCE));
Having said that, if you really need to create your own operators, the
easiest way, as you mention, is to create your operator (which would extend
the Calcite operator) and your rule (which could extend the Calcite rule,
but not necessarily). As you say, it is not possible to use the
Immutable*Rule Config, but you can use the rule's default Config or create
your own default Config. You can even do all that without Immutables in
your project, this thread might be of interest [1].
Best,
Ruben
[1] https://lists.apache.org/thread/2h0mcdqs4q1psgjy9sxlk8wxzo3w1zq9
On Fri, Sep 16, 2022 at 10:10 PM Pranav Deshpande <
[email protected]> wrote:
> Hi Julian/Apache Calcite Dev Team,
> Thank you very much for your reply
> I see that's a good point and it makes a lot of sense. I think I should
> exactly tell you what my problem is: I am only trying to override the cost
> function so that I can group operators in a certain way in the Relational
> Tree.
>
> That is the only functionality that is required (for my example) right now.
> I was extending the rules and the nodes to override this 1 function only.
> Is there another way to do this? If not, what is the recommended approach
> (is it to duplicate the enumerable rels and rules)?
>
> Please let me know.
>
> Thanks & Regards,
> Pranav
>
> On Fri, Sep 16, 2022 at 3:13 PM Julian Hyde <[email protected]>
> wrote:
>
> > We don’t necessary want you to extend existing classes. If we change the
> > base class in future, your code breaks, and you complain that we have
> > broken semantic versioning. Making things private is, in that sense, a
> > feature.
> >
> > If what you are doing is a feature that would benefit other Calcite
> users,
> > you should propose that feature.
> >
> > Julian
> >
> >
> > > On Sep 16, 2022, at 11:41 AM, Pranav Deshpande <
> > [email protected]> wrote:
> > >
> > > Dear Apache Calcite Team,
> > > I am trying to modify some parts of the RelNode Tree in Calcite for my
> > own
> > > custom logic. For this, I am extending existing nodes (eg.
> > > EnumerableAggregate etc.) and then also extending the respective rule
> > (eg.
> > > EnumerableAggregateRule) and overriding the respective functions in
> both
> > so
> > > that my custom node is used in the tree (logical -> custom node which
> is
> > > basically an extended enumerable) instead of logical -> enumerable.
> > >
> > > Some of the rules here (eg. EnumerableLimit) have references to
> Immutable
> > > classes which are package private and I hence I am unable to extend
> these
> > > (EnumerableLimitRule is itself one such example:
> > >
> >
> https://github.com/apache/calcite/blob/b9c2099ea92a575084b55a206efc5dd341c0df62/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableLimitRule.java#L72
> > > )
> > >
> > > Any advice on how I can solve this problem?
> > >
> > > Thanks & Regards,
> > > Pranav
> >
> >
>
