[
https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773344#comment-15773344
]
Joel Bernstein edited comment on SOLR-8593 at 12/23/16 5:40 PM:
----------------------------------------------------------------
I think I have a handle now on how the *string* and *arithmetic* functions
work. I was expecting them to work automatically and Calcite would perform the
functions if we returned data in the fields.
I now believe that is not the case, because we've pushed down the projection.
Because we've pushed down the *projection* we'll need to implement the
arithmetic and string functions using the *SelectStream*. What Calcite provides
in the project rule is access to the parse tree so we have enough information
to implement the functions.
Since this ticket was mainly about getting parity with the current SQL
functionality, I think it makes sense to tackle the string and arithmetic
functions in a separate ticket. I will create that ticket.
was (Author: joel.bernstein):
I think I have a handle now on how the *string* and *arithmetic* functions
work. I was expecting them to work automatically and Calcite would perform the
functions if we returned data in the fields.
I now believe that is not the case, because we've pushed down the projection.
Because we've pushed down the projection we'll need to implement the arithmetic
and string functions using the SelectStream. What Calcite provides in the
project rule is access to the parse tree so we have enough information to
implement the functions.
Since this ticket was mainly about getting parity with the current SQL
functionality, I think it makes sense to tackle the string and arithmetic
functions in a separate ticket. I will create that ticket.
> Integrate Apache Calcite into the SQLHandler
> --------------------------------------------
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
> Issue Type: Improvement
> Reporter: Joel Bernstein
> Assignee: Joel Bernstein
> Attachments: SOLR-8593.patch, SOLR-8593.patch
>
>
> The Presto SQL Parser was perfect for phase one of the SQLHandler. It was
> nicely split off from the larger Presto project and it did everything that
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where
> Apache Calcite comes into play. It has a battle tested cost based optimizer
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans
> will continue to be translated to Streaming API objects (TupleStreams), so
> continued work on the JDBC driver should plug in nicely with the Calcite work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
