[
https://issues.apache.org/jira/browse/CALCITE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240369#comment-14240369
]
Vladimir Sitnikov commented on CALCITE-506:
-------------------------------------------
{quote}There's no advantage to generating Java; its performance would not be
affected if it was implemented as an interpreter. Then what you pass to it is
not a pre-computed string but (a copy of) the root RelNode.{quote}
Well. I do not expect "enumerable to rule the world".
Currently enumerable is the only executor engine that have good coverage (join,
sort, group by, order by, etc, etc) and the one that is easy to use.
I am not yet fond of reimplementing all the nodes in "interpreter convention".
I just pick the easiest approach that meets my requirements.
Some good interpreter with row batching, on-stack replacement, statistics
collection and adaptive behavior (e.g. decide between hash join and nested
loops based on the actual number of rows) would be good :)
{quote}and execute it on node 2. That means that all objects we pass between
planner and executor have to be serializable or externalizable.{quote}
That is true. I do not think we need "generic" solution. I want to solve simple
problem: solve it just for java-kind of executors.
I do not even consider passing arbitrary data types from client to server over
RPC. I mean just "reuse of the same java object" between planning (toRel) and
execution phases (in enumerable or in interpreter).
> Update EnumerableRelImplementor.stash so it is suitable for all kinds of
> classes
> --------------------------------------------------------------------------------
>
> Key: CALCITE-506
> URL: https://issues.apache.org/jira/browse/CALCITE-506
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Labels: newbie
>
> {code:java}
> public Expression stash(RelNode child, Class clazz) {
> final ParameterExpression x = register(child, clazz);
> final Expression e = Expressions.call(getRootExpression(),
> BuiltInMethod.DATA_CONTEXT_GET.method, Expressions.constant(x.name));
> return Expressions.convert_(e, clazz);
> }
> {code}
> I would like to make two corrections here:
> 1) I think {{public <T> Expression st(T x, Class<? super T> clazz) \{}}
> should be better signature.
> 2) It makes sense to translate {{DATA_CONTEXT_GET}} as a store to a {{final}}
> local variable at the very start of {{public
> org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root0)}} method (see {{implementRoot}}), so at
> the usage time it is just a load of local variable, not a {{map.get}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
