[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752805#comment-15752805 ] Julian Hyde edited comment on SOLR-8593 at 12/15/16 11:13 PM: -------------------------------------------------------------- I wasn't familiar with faceting, but I quickly read https://wiki.apache.org/solr/SolrFacetingOverview. Suppose table T has fields a, b, c, d, and you want to do a faceted search on b, a. If you issue the query {{select b, a, count\(*) from t group by b, a}} then you will end up with {code} Project(\$1, \$0, \$2) Aggregate({0, 1}, COUNT(*)) Scan(table=T) {code} and as you correctly say, {0, 1} represents {a, b} because that is the physical order of the columns. Can you explain why the faceting algorithm is interested in the order of the columns? Is it because it needs to produce the output ordered or nested on those columns? If so, we can rephrase the SQL query so that we are accurately expressing in relational algebra what we need. was (Author: julianhyde): I wasn't familiar with faceting, but I quickly read https://wiki.apache.org/solr/SolrFacetingOverview. Suppose table T has fields a, b, c, d, and you want to do a faceted search on b, a. If you issue the query {{select b, a, count(*) from t group by b, a}} then you will end up with {code} Project(\$1, \$0, \$2) Aggregate({0, 1}, COUNT(*)) Scan(table=T) {code} and as you correctly say, {0, 1} represents {a, b} because that is the physical order of the columns. Can you explain why the faceting algorithm is interested in the order of the columns? Is it because it needs to produce the output ordered or nested on those columns? If so, we can rephrase the SQL query so that we are accurately expressing in relational algebra what we need. > 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: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org