You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2020/12/02 09:46:32 UTC

[GitHub] [shardingsphere] tristaZero commented on issue #8284: [New feature] Federated SQL query and Query optimization are going to sail out.

tristaZero commented on issue #8284:
URL: https://github.com/apache/shardingsphere/issues/8284#issuecomment-737116690


   Hi, @junwen12221 
   
   > Its input is logical RelNode, and its output is also logical RelNode, they are all Convention.NONE. Unlike ConverterRule from one Convention RelNode to another Convention RelNode.
   
   If `CoreRules` is in the field of `Convention.NONE` and has nothing to do with `Calling convention`, what's the role of `CoreRules` for relNode optimization?
   
   Also, here are some of my thinking about this issue. If I missed something, welcome your correction. :)
   1. It is possible to implement the custom adaptor for federated queries.
   2. We need to consider SQL optimization. If we use Calcite JDBC Driver, the only way to affect the optimization process is to override the interface for different kinds of tables like `TranslatableTable` and provide `RelOptRule`. 
   3. On the other hand, we may try to skip Calcite JDBC Driver and call the `parse`, `validate`, `optimize` and `execute` functions in our  new `custom execute Driver`, which needs a in-depth understanding about the source code of Calcite and coding work.
   4. By 3, we can use our parser engine to parse SQL instead of Calcite parser, providing a broad SQL support as our SQL parser can parse SQLs from different databases dialects.


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org