-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
In the match statement, the where condition may generate unnecessary storage queries #3257
Comments
This looks like a few errors superimposed together and ultimately ensure the correct query results. |
"1"==1 is true in sql but false in cypher. Our current logic of expression is consistent with cypher and the index logic related should be consistent. IMHO, This is just the behavior of the expression, and the implementation of other modules should be delegated to it. More detail please refer to cypher standand. |
In my mind, index scan which transformed from filter expression should keep the origin semantic of expression. |
This would not be fixed at present due to the syntax matter of openCypher. |
Statement
a
andb
will generate request to storage and get the same response. Because encode of"a"
and-2233785415175766016
is same in indexKey and there is not value type verify.However, according to the code given above, we find that the result is different. According to the profile statement, a filter node is actually added to the execution plan and filtered again according to the condition.
So, there are some questions
match
statement, we can compare values between different types (only==
). But there is no type conversion, so the result of the expression is always false. If we want to support the comparison of weak data types, like sql, "1"==1 is true, then our current logic is not correct. If we need a comparison of strong data types, then "1"==1 will always return false, which is meaningless. The query results can be known during query optimization.The current processing logic will only waste CPU resources==
, it should also support comparison operations such as<
,>
, but currently it is not supported.The text was updated successfully, but these errors were encountered: