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

Julian Hyde commented on SOLR-8593:
-----------------------------------

Not sure I understand. The query {{select a from b limit 10}} will have a 
{{Sort}} whose key has zero fields but which has fetch = 10. The {{Sort}} will 
be translated to a {{SolrSort}} with similar attributes. The sort is trivial - 
that is, you don't need to do any work to sort on 0 fields - but you do need to 
apply the limit. If you see a {{SolrSort}} with empty keys, don't drop it, but 
maybe convert into a {{SolrLimit}} if you have such a thing.

You may be wondering why we combine sort and limit into the same operator. But 
remember that relational data sets are inherently unordered, so we have to do 
them at the same time. Sort with an empty key has reasonable semantics, just as 
-- I hope you agree -- Aggregate with an empty key (e.g. {{select count(*) from 
emp}}, which is equivalent to {{select count(*) from emp group by ()}}) is a 
reasonable generalization of Aggregate.

> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to