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 2021/03/30 06:30:24 UTC

[GitHub] [shardingsphere] guimingyue commented on pull request #9847: Dev

guimingyue commented on pull request #9847:
URL: https://github.com/apache/shardingsphere/pull/9847#issuecomment-809950043


   > Sorry, the PR is so big, I think nobody can review it, could you split them to smaller PRs?
   
   Hi, @terrymanu , sorry for the late reply. In my perspective, this PR is regraded as a whole of federated SQL query. Most of the classes of this PR are newly added. Let me try to explain the PR in detail.
   
   This PR can be divided into three parts, `shardingsphere-infra-optimize` module, `shardingsphere-infra-executor` module and the glue code(mainly in shardingsphere-jdbc-core module) which is responsible for connecting the `shardingsphere-infra-optimize` and `shardingsphere-infra-executor`.
   
   0. The `shardingsphere-infra-optimize` module is a new module, and is based on Apache Calcite framework. It contains the converter of converting ShardingSphere ast to Calcite ast, or `SqlNode` in Calcite world, and the Converter of converting `SqlNode` to `RelNode` of Calcite. The most important part of this module is the optimizer based on Calcite Planner framework, containing planner rules, logical RelNode and physical RelNode, please refer to `DefaultPlanner` for this process. `org.apache.shardingsphere.infra.optimize.planner.Compiler#compileQuery` this method is the entrance of converting ast and optimizing relnode, and this method alse return the physical RelNode to execute in `shardingsphere-infra-executor` module.
   1. The `shardingsphere-infra-executor` module is an existing module. But there is a new package `exec`, in this package, the main part is `Executor`s,and they are the implementation of phycical RelNode. For example the NestedLoopJoinExecutor is the implemantation of physical RelNode SSNestedLoopJoin. Some Executors need to execute function to filter or aggregate rows, so that's what `BuiltinFunction` does. When building Executor instance,  `BuiltinFunction` may be created and passed to `Executor` instance, for example, `org.apache.shardingsphere.infra.executor.exec.CalcExecutor#build` create `BuiltinFunction` for filter operator to filter rows. 
   2. Besides the optimizer and executor, some glue code is added to implementation a whole query process. In `ShardingSphereStatement`, there is a new method `org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSphereStatement#executeSql` to execute SQL with optimizer and executor, this method is enabled by a preperty `federated-sql-query-optimization` in `org.apache.shardingsphere.infra.config.properties.ConfigurationPropertyKey`. In the same module, a new class `SSResultSet` is also newly added for retrieving `Row` from `Executor` in  `shardingsphere-infra-executor` module.
   
   I alse deleted previous calcite related method and testcase, because most of them have nothing to do with federated SQL query.


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