Re: Quicksql

Hi Haisheng, > The query on different data source will then be registered as temp spark > tables (with filter or join pushed in), the whole query is rewritten as SQL > text over these temp tables and submitted to Spark. Does it mean QuickSQL also need adaptors to make query executed on

Re: Re: Quicksql

As far as I know, users still need to register tables from other data sources before querying it. QuickSQL uses Calcite for parsing queries and optimizing logical expressions with several transformation rules. The query on different data source will then be registered as temp spark tables (with

Re: Quicksql

The co-routine model sounds fitting into Streaming cases well. I was thinking how should Enumerable interface work with streaming cases but now I should also check Interpreter. -Rui On Tue, Dec 10, 2019 at 1:33 PM Julian Hyde wrote: > The goal (or rather my goal) for the interpreter is to

Re: Quicksql

The goal (or rather my goal) for the interpreter is to replace Enumerable as the quick, easy default convention. Enumerable is efficient but not that efficient (compared to engines that work on off-heap data representing batches of records). And because it generates java byte code there is a

[jira] [Created] (CALCITE-3586) ToLogicalConverter should not create plans with nodes in different clusters

Stamatis Zampetakis created CALCITE-3586: Summary: ToLogicalConverter should not create plans with nodes in different clusters Key: CALCITE-3586 URL: https://issues.apache.org/jira/browse/CALCITE-3586

Re: Quicksql

What is the ultimate goal of the Calcite Interpreter? To provide some context, I have been playing around with calcite + REST (see https://github.com/zolyfarkas/jaxrs-spf4j-demo/wiki/AvroCalciteRest for detail of my

Re: Quicksql

The guys at Contiamo [1] are doing similar stuff. I added the nice talk [2] by Chris in ApacheCon to our website. [1] https://www.contiamo.com/ [2] https://youtu.be/4JAOkLKrcYE On Tue, Dec 10, 2019 at 3:05 AM Julian Hyde wrote: > Yes, virtualization is one of Calcite’s goals. In fact, when I

[jira] [Created] (CALCITE-3585) Deprecate EnumerableJoinRule in favor of EnumerableHashJoinRule + EnumerableNestedLoopJoinRule

Ruben Q L created CALCITE-3585: -- Summary: Deprecate EnumerableJoinRule in favor of EnumerableHashJoinRule + EnumerableNestedLoopJoinRule Key: CALCITE-3585 URL: https://issues.apache.org/jira/browse/CALCITE-3585

[jira] [Created] (CALCITE-3584) Support SQL hints propagation for decorrelation

Danny Chen created CALCITE-3584: --- Summary: Support SQL hints propagation for decorrelation Key: CALCITE-3584 URL: https://issues.apache.org/jira/browse/CALCITE-3584 Project: Calcite Issue

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Stamatis>I mean that there are a few people who are a bit skeptical with the change Stamatis>so it seems that more convincing elements are needed. There's no way to convince people who do not want to analyze Checkstyle / build configuration themselves. Everybody was happy with Maven, and there