逻辑查询计划重构优化

       目前，IoTDB在查询引擎的逻辑查询计划上主要存在以下几个问题：

2.1.1 存在问题

• 类继承关系设计不合理

       如下图2.2所示，当前逻辑查询运算符 QueryOperator 继承自SFWOperator，后者代表由Select、From、Where三个子句组成的逻辑运算符。一般来说，只有查询语句会同时包含这三个部分。但是由于IoTDB特殊的数据模型，Select子句中会包含时间序列的后缀路径，而From子句中会包含时间序列的前缀路径，为了能够简便的使用Select或From运算符中的路径存储结构，Insert或Delete等语句的逻辑运算符也继承了这一基类。这种继承关系的抽象显然是不合理的，造成了结构的混乱和存储的冗余，应该根据每个语句的实际情况增加相应的成员变量，例如DeleteDataOperator内只需要增加完整路径的数组即可。

...

图2.4 SelectOperator内部存储结构图

2.1.2 解决方案

       首先，Insert和Delete等运算符继承SFWOperator是没有必要的，因此计划为其增加需要的路径变量后，直接作为基类Operator的子类。此时，只有QueryOperator继承自SFWOperator，因此可以将SFWOperator内部的成员变量，即Select、From、Where部分，直接移至QueryOperator，从而移除SFWOperator。

...

       最后，我们得到的整体的类图，如下图所示：

图2.9 逻辑查询计划设计总类图

Select 子句

antlr语法定义

resultColumn
: expression (AS ID)?
;

expression
: LR_BRACKET unary=expression RR_BRACKET
| (PLUS | MINUS) unary=expression
| leftExpression=expression (STAR | DIV | MOD) rightExpression=expression
| leftExpression=expression (PLUS | MINUS) rightExpression=expression
| functionName=suffixPath LR_BRACKET expression (COMMA expression)* functionAttribute* RR_BRACKET
| suffixPath
| literal=SINGLE_QUOTE_STRING_LITERAL
;

functionAttribute
: COMMA functionAttributeKey=stringLiteral OPERATOR_EQ functionAttributeValue=stringLiteral
;

数据结构

ResultColumn

包含Expression和alias两个字段，封装了对Expression的操作。

Expression

本质是ANTLR语法树的内存镜像。

BinaryExpression

...