Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizer rules compatibility #3704

Closed
czpmango opened this issue Jan 12, 2022 · 1 comment · Fixed by #3736
Closed

Optimizer rules compatibility #3704

czpmango opened this issue Jan 12, 2022 · 1 comment · Fixed by #3736
Assignees
Labels
type/bug Type: something is unexpected
Milestone

Comments

@czpmango
Copy link
Contributor

czpmango commented Jan 12, 2022

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

  1. 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
  1. Expression design should be reconsidered

    • reconsider data dependency design
    • avoid redundant design of expression types, eg. VarProperty/InputProperty/LabelTagProperty/LabelProperty, etc
  2. Define the promises to optimizer to avoid errors like this pr

    • what types of plannode/expression should be taken into account (eg. LabelTagProperty or VarProperty 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 or planner 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
    • ...
@czpmango czpmango added the type/bug Type: something is unexpected label Jan 12, 2022
@Sophie-Xie Sophie-Xie added this to the v3.0.0 milestone Jan 12, 2022
@Shylock-Hg
Copy link
Contributor

Shylock-Hg commented Jan 14, 2022

To avoid these happen again, we could add more test cases which compare the optimized plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug Type: something is unexpected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants