[
https://issues.apache.org/jira/browse/SOLR-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551077#comment-17551077
]
Joel Bernstein edited comment on SOLR-16238 at 6/7/22 1:33 PM:
---------------------------------------------------------------
Thanks [~krisden]!
I think I'm most interested in understanding how the planner interacts with the
rules. For example I noticed that if I do a join, Calcite will do it correctly.
But if I do an aggregation on top of a join Calcite throws an error that it
doesn't have enough rules.
What I suspect is going on is that we don't have a logical join rule
implemented so Calcite takes over in the join without agg query. But we do have
an Aggregation rule, so with the join with agg query, Calcite starts to
implement our rule, but then fails when it realizes we don't have a join rule.
The way to resolve this would likely be to return null from the aggregation
rule if we see a join in the tree. But the mechanics of seeing the whole parse
tree are unclear. For example in the agg with join scenario, do we need to
implement a join rule that returns null for Calcite to understand that we want
the Calcite planner to take over?
was (Author: joel.bernstein):
Thanks [~krisden]!
I think I'm most interested in understanding how the planner interacts with the
rules. For example I noticed that if I do a join, Calcite will do it correctly.
But if I do an aggregation on top of a join Calcite throws an error that it
doesn't have enough rules.
What I suspect is going on is that we don't have a logical join rule
implemented so Calcite takes over in join without agg query. But we do have an
Aggregation rule, so with the join with agg query, Calcite starts to implement
our rule, but then fails when it realizes we don't have a join rule. The way to
resolve this would likely be to return null from the aggregation rule if we see
a join in the tree. But the mechanics of seeing the whole parse tree are
unclear. For example in the agg with join scenario, do we need to implement a
join rule that returns null for Calcite to understand that we want the Calcite
planner to take over?
> Code level documentation for Solr SQL
> -------------------------------------
>
> Key: SOLR-16238
> URL: https://issues.apache.org/jira/browse/SOLR-16238
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Parallel SQL
> Reporter: Joel Bernstein
> Assignee: Joel Bernstein
> Priority: Major
> Labels: RobustSQL
>
> The Solr SQL module is an Apache Calcite adaptor. I find the Apache Calcite
> framework quite confusing. So, for my own knowledge and for future devs who
> want to contribute to Solr SQL, I'd like to take the time to document the
> code thoroughly.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
