lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Bernstein (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
Date Wed, 01 Feb 2017 19:50:52 GMT

    [ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848856#comment-15848856
] 

Joel Bernstein edited comment on SOLR-8593 at 2/1/17 7:50 PM:
--------------------------------------------------------------

We've run into a bug with pushing down of the SQL LIMIT clause. Currently we have code that
handles the limit in the SolrSort class which extends org.apache.calcite.rel.core.Sort.

This issue is that the SolrSort rule is only executed if an ORDER BY clause is included. So
if LIMIT is used without an ORDER BY our code does not see the LIMIT.

So limit works in this scenario:

*select a from b order by a limit 10*

but not this scenario:

*select a from b limit 10*

[~julianhyde], any ideas on how to resolve this?




was (Author: joel.bernstein):
We've run into a bug iwith pushing down of the SQL LIMIT clause. Currently we have code that
handles the limit in the SolrSort class which extends org.apache.calcite.rel.core.Sort.

This issue is that the SolrSort rule is only executed if an ORDER BY clause is included. So
if LIMIT is used without an ORDER BY our code does not see the LIMIT.

So limit works in this scenario:

*select a from b order by a limit 10*

but not this scenario:

*select a from b limit 10*

[~julianhyde], any ideas on how to resolve this?



> Integrate Apache Calcite into the SQLHandler
> --------------------------------------------
>
>                 Key: SOLR-8593
>                 URL: https://issues.apache.org/jira/browse/SOLR-8593
>             Project: Solr
>          Issue Type: Improvement
>          Components: Parallel SQL
>            Reporter: Joel Bernstein
>            Assignee: Joel Bernstein
>             Fix For: 6.5, master (7.0)
>
>         Attachments: SOLR-8593.patch, 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.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message