paul-rogers commented on issue #12262:
URL: https://github.com/apache/druid/issues/12262#issuecomment-1184715839
> We can't drop support for the current monolithic native queries, which
means ... we need to be able to convert them to operator trees that can run
just-as-well.
Exactly. That's what the operator prototype does: it uses the native query
as the "plan" and generates operators for the pipeline operators outside of the
parts that work with segments. That is, the merges, limits, offsets, sorts,
exchanges, distributions, retries, etc. This proof-of-concept shows that a DAG
model works just as well for SQL as for native queries.
The planner could be of the form:
```text
native query --> native query planner
--> logical plan --> optimizer -->
physical plan --> operators
sql --> sql planner
```
The above is a pretty typical way that query engines handle this kind of
thing. The prototype uses an abbreviated path to keep things simple:
```text
native query --> native query planner --> operators
```
But, the prototype isn't distributed (yet), so could omit the physical plan
stage. The prototype does some optimization (omit a merge if there is only one
input, say, or omit steps which don't apply to the query). A "real" optimizer
would also do the distribution planning of the kind done in the present ingest
MSQE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
