Closed
Description
Describe the bug (required)
This pr (#3255) should fix all related optimizer rules, because the expression related processing logic has been changed(VarPropertyExpression/InputPropertyExpression -> LabelTagPropertyExpression).
Your Environments (required)
Versions after this pr(#3255)
How To Reproduce(required)
Just check all expression related OptRule code logic.
Additional context
- Some logic of this pr maybe also need been retested
(root@nebula) [nba]> with {a:1, b:{c:3, d:{e:5}}} as x return x.b.d.e
[ERROR (-1009)]: SemanticError: The type of `x' should be tag
-
Expression design should be reconsidered
- reconsider data dependency design
- avoid redundant design of expression types, eg. VarProperty/InputProperty/LabelTagProperty/LabelProperty, etc
-
Define the promises to optimizer to avoid errors like this pr
- what types of plannode/expression should be taken into account (eg.
LabelTagProperty
orVarProperty
in this pr) - data dependency and execution dependency conflict
- column names should be set before optimization phase (this currently may cause some potential optimization rule bugs)
- in what scenario dose reuse of executor dataset should be concerned(eg. Filter outputVar)
- execution plans should be guaranteed to be stateless (eg.
validator
orplanner
setting some context states on which execution plans depend should be disabled) - expression conversion to
Value
, which is really different from expression rewriting, needs to be disabled or concerned. (eg. ColumnHints design) - clause level and planner's cutting of statements needed to be redesigned(eg. WHERE is not a clause in its own right — rather, it’s part of MATCH, OPTIONAL MATCH, START and WITH), this may improve some code logic related to
DataCollect
- ...
- what types of plannode/expression should be taken into account (eg.
Activity
Shylock-Hg commentedon Jan 14, 2022
To avoid these happen again, we could add more test cases which compare the optimized plan.