I am trying to "separate" certain subsets of Operators in a query tree and
transform them to a more "general" RelNode implementation, that holds the
information required to rebuild them. I want to implement something more
general than CALC (for more types of operators), that works like this:
Opera
It seems that "composite" operators crop up quite often. Having kept
the operators separate in older adapters like the Mongo adapter, I
took a different approach in Druid adapter, and I'm quite please with
it.
DruidQuery contains a "stack" of internal relational operators. They
are held in the fie
Hello,
I tried to write something by myself, and your example helped. However, I
am stuck with this error:
I have created an operator that holds the proper info (program1, program2,
AggList, GroupList, ...) about two CALCs and one Aggregate in the following
formation:
(Calc1->Aggregate->Calc2) =>
In order to make it work, I had to specifically define my rowtype in the
core operator I have created:
public abstract class AggrCalc extends SingleRel{
...
// constructor
protected AggrCalc(...) {
super(cluster, traits, child);
this.rowType = wantedRowType;
}
}
I am not sure if this is
Yes, sometimes you have to do this. I agree that it’s a pain. You have to
satisfy the Volcano planner by supplying an identical row-type (field names can
be different, but types must be the same down to nullability, precision and
scale). But the uniformity demanded by Volcano has benefits elsewh
