Re: Support UUID type in Calcite

It would be a lot of work to support it as a new physical type (e.g. we would have to modify Avatica). Easier to support as a logical type, similar to what we did with Geometry. Its physical type would be, say, BINARY(16). Julian > On Aug 23, 2018, at 5:56 PM, Shuyi Chen wrote: > > Do we

Re: Casting from BIGINT to TIMESTAMP in Calcite?

I bet the semantics you have in mind makes some reference to the 1970-01-01 UNIX epoch. The SQL standard makes no mention of that epoch. Converting numbers to timestamps is “obvious” only in that frame. I don’t think it’s “obvious” enough for it to be the behavior of CAST. If you want to

Support UUID type in Calcite

Do we want to add support for UUID type in Calcite? Databases like vertica and postgre are already supporting UUID type? Thanks. Shuyi -- "So you have to trust

Casting from BIGINT to TIMESTAMP in Calcite?

Currently, SqlValidator does not allow casting from BIGINT to TIMESTAMP. Is there any reason that we don't support such CAST rule, or it is fine that we add it in Calcite? Thanks a lot. Shuyi -- "So you have to trust that the dots will somehow connect in your future."

[jira] [Created] (CALCITE-2488) Samza SQL : Support all the timestamp functions from calcite

Srinivasulu Punuru created CALCITE-2488: --- Summary: Samza SQL : Support all the timestamp functions from calcite Key: CALCITE-2488 URL: https://issues.apache.org/jira/browse/CALCITE-2488

Re: Assign alias to a column in RelBuilder

As Andrei says, using "RelBuilder.alias(RexNode, String)” on an expression in RelBuilder.project works. But only most of the time - RelBuilder reserves the right to discard projects that do nothing more than rename columns. Try using RelBuilder.rename. It will force creation of a Project even

Re: Assign alias to a column in RelBuilder

The following works for me @Test public void relBuilderProjectAlias() throws Exception { final RelBuilder builder = RelBuilder.create(config().build()); final RelNode root = builder.scan("EMP") .project( builder.alias(builder.field("EMPNO"), "aaa"),

Re: full table scans and subQueryThreshold

Hi Zoltan, Thanks for your reply. I also found CALCITE-1321 which is related (defining threshold parameter) but not the same. The discussion there points the preference for planner rule (instead of SqlToRelConverter). Do you know how

Assign alias to a column in RelBuilder

Hi All, I am using RelBuilder to build relational expression and then converting it to a SQL query using Rel2SqlConverter. I skimmed through the examples of RelBuilder but

Re: graphql query to sql query with Calcite ?

I’d call that a "GraphQL front-end for Calcite". (SQL is our main front end, but other front-ends include linq4j and I gather there are other query languages in commercial products, e.g. Stardog uses Calcite to translate SPARQL to SQL[1].) I think this is a good fit for Calcite, and would

Re: [DISCUSS] Avatica - how efficient is our protocol?

I remember when I was doing some old benchmarks, I had to build some custom logic to get writes happening at a decent speed (some basic batching and avoiding deserializing things when I could). I'm sure there is much more we can do here, especially around our HTTP transport. My impression is

[jira] [Created] (CALCITE-2487) Upgrade Apache parent POM to version 21

Julian Hyde created CALCITE-2487: Summary: Upgrade Apache parent POM to version 21 Key: CALCITE-2487 URL: https://issues.apache.org/jira/browse/CALCITE-2487 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-2486) Upgrade Apache parent POM to version 21

Julian Hyde created CALCITE-2486: Summary: Upgrade Apache parent POM to version 21 Key: CALCITE-2486 URL: https://issues.apache.org/jira/browse/CALCITE-2486 Project: Calcite Issue Type: Bug

Re: [DISCUSS] Avatica - how efficient is our protocol?

Sounds like a very interesting issue. While I’m evaluating Calcite for JDBC adaptor over postgreSQL with TPC-DS queries, where Calcite queries 2~10 times slower than native postgresql queries through psql. So, including JDBC latency issues, overall enhancement of Avatica would be beneficial

[DISCUSS] Avatica - how efficient is our protocol?

This is a paper in VLDB 2018, "Don’t Hold My Data Hostage – A Case For Client Protocol Redesign” by Mark Rassveldt and Hannes Muhleisen[1]. It claims that database client protocols (inside ODBC and JDBC drivers) are very inefficient, and has a compelling example where commercial drivers are 10x

Re: full table scans and subQueryThreshold

Hello Andrei! I've also bumped into this earlier - from a little bit different angle :) I've found some "back story about it": It works currently like this because a long time ago there was no other way to do the subquery conversion of IN; I think now the preferred way would be to have a rule