calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stamatis Zampetakis <zabe...@gmail.com>
Subject Re: Difficulties with implementing a table for a custom convention
Date Sun, 05 May 2019 21:34:58 GMT
Hi Muhammad,

I'm not sure why you need to implement InterpretableRel interface. I'm
probably missing some details.

I suppose you are using Calcite through the JDBC interface thus I guess you
are relying on CalcitePrepareImpl.
If that's the case then using TranslatableTable interface seems like a good
idea.
The latter means that you are using the default VolcanoPlanner that expects
the final result to be in Bindable or Enumerable convention [2].
You may define various operators and tables to be in CustomConvention but
for sure you need a Converter
and respective rules to go from CustomConvention to EnumerableConvention
(similar to MongoToEnumerableConverter and MongoToEnumerableConverterRule).

The final plan should look be similar to the one below:

CustomToEnumerableConverter
  CustomProject(product_id=[CAST(ITEM($0, 'product_id')):DOUBLE])
    CustomTableScan(table=[[_foodmart, sales_fact_1998]])"

Best,
Stamatis

[2]
https://github.com/apache/calcite/blob/0d504d20d47542e8d461982512ae0e7a94e4d6cb/core/src/main/java/org/apache/calcite/prepare/CalcitePrepareImpl.java#L719

On Sun, May 5, 2019 at 4:13 AM Yuzhao Chen <yuzhao.cyz@gmail.com> wrote:

> You can set up the target traits to include the convention you want when
> invoke the Program#run method [1], with the converters as rules of the
> program.
>
> [1]
> https://github.com/apache/calcite/blob/9ece70f5dcdb00dbc6712496c51f52c05178d4aa/core/src/main/java/org/apache/calcite/tools/Program.java#L38
>
> Best,
> Danny Chan
> 在 2019年5月4日 +0800 PM6:48,Muhammad Gelbana <m.gelbana@gmail.com>,写道:
> > I implemented a new convention but I'm facing difficulties with
> > implementing tables for that convention.
> >
> > Since I need to apply my convention rules and converters, I assume I must
> > implement TranslatableTable so I can override the RelNode produced by the
> > toRel method and provide the rules I need through the
> > RelNode.register(RelOptPlanner planner) call back (Is there another way
> ?)
> >
> > At the same time, I need for my table's RelNode to implement my
> > convention's interface.
> >
> > After implementing TranslatableTable and my convention's interface, I
> > discovered that my table's RelNode have to either implement an
> interpreter
> > node or the InterpretableRel interface. But this led to what seems to me
> as
> > that my table scan is executed twice.
> >
> > I tried many things, such as having my table extend TableScan,
> > AbstractEnumerable2 QueryableTable and other interfaces/class that either
> > didn't give me what I want or failed with strange exceptions.
> >
> > What I need is to implement my table scan following the same convention
> I'm
> > writing. So what is the correct way to do this ?
> >
> > The MongoDB adapter way is to implement the TranslatableTable and the
> > QueryableTable interfaces, but that's confusing me. I mean, it's already
> > implementing its own new convention interface, why would it need to
> > implement another one to implement its table scans ? I thought while
> > executing the final plan, the first calcite identified node (enumerable
> or
> > bindable, enumerable as in MongoDB adapter's example), the interpreter
> > would execute that node, which will internally execute all its input
> nodes
> > including the table scan, correct ?
> >
> > Thanks,
> > Gelbana
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message