calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Review calcite-445
Date Sun, 22 Feb 2015 18:55:55 GMT

Per your earlier suggestion, I have broken up the create2 method. See the latest commit in
the calcite-445 branch.

> On Feb 22, 2015, at 10:08 AM, Vladimir Sitnikov <> wrote:
>> Longer term I would like EnumerableTableScan to work only on top of a QueryableTable
> Why's that?
> If there is no expression, you can just EnumerableRelImplementor.stash
> the "any_table" and that is it. No expression is required.
> Just-in-time stashing to rescue.
> However, I do agree it makes sense to dodge
> RelOptTableImpl.getExpression: I agree there are cases when expression
> is known only at parse-time (e.g. as a result of
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor#stash)

Thanks for that concession. There will be cases for all 3: Enumerable with stash, using Bindable
convention and no code generation, and full code generation. I just want Calcite users to
be able to choose.

>> You can't understand how broken it was unless you run testStream and try to get it
> Our typical strategy was "test is a detailed design", however for
> streamable it is not yet the case.
> I do not like how you sneak BINDABLE rules in while "ENABLE_BINDABLE=false".
> Can you clarify what do you mean by stream tables? How it should work?

I don't have time to explain all of it. The work isn't finished yet. Watch the chi branch,
issue CALCITE-602, the dev list and the samza dev list.

> I cannot understand how it is supposed to work. All the rules just
> eliminate LogicalDelta.

For now, yes.

> I believe I can kill all the bindable rules and manage testStream to
> fly, however I do not want to get my hands dirty on the thing that
> should work in unknown to me fashion.

Good -- it would be great if you could make these cases work with Interpreter disabled. Don't
kill the bindable rules, just disable them.

> Is the sole purpose of StreamableTable that it returns a table on demand?
> How it is different from regular table/table macro/table function?

Streaming is a significant extension to relational algebra. Analogous to adding differentiation
and integration to the algebra of polynomial functions. You can't emulate the delta and chi
operators in terms of existing ones. Read
for more of the theory.

>> ImmutableIntList#identity create an AbstractList<Integer> (
> I do not follow you. ImmutableIntList#identity should create just
> ImmutableIntList. What's verbose and less efficient with that?

It can't do it in terms of #range because range does not return an ImmutableIntList.

>> This is emulating the behavior of ReflectiveTable and FieldSelector. I put it in
to make existing tests work.
> Why emulate if you can reuse?
> Who guarantees that those implementations would not diverge in the future?

I don't believe reuse is possible, otherwise I would have done it.


View raw message