You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(root@nebula) [test]> create tag index t_name_index on t(name(8));
(root@nebula) [test]> insert tag t(name) values 1:("a");
(root@nebula) [test]> match (v:t) where v.name=="a" return v; // a
+-------------------+
| v |
+-------------------+
| (1 :t{name: "a"}) |
+-------------------+
Got 1 rows (time spent 14400/15023 us)
Tue, 02 Nov 2021 18:31:53 CST
(root@nebula) [test]> match (v:t) where v.name== -2233785415175766016 return v; // b
+---+
| v |
+---+
+---+
Empty set (time spent 14978/15568 us)
Tue, 02 Nov 2021 18:32:00 CST
Statement a and b 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.
In the 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
If we want to implement the comparison of weak data types, then it should not be limited to ==, it should also support comparison operations such as <, >, but currently it is not supported.
In this case, the expressions are all used for index optimization, so it is not necessary to perform another filter after selecting the index (if the logic we implemented is correct)
The text was updated successfully, but these errors were encountered:
If we want to support the comparison of weak data types, like sql, "1"==1 is true, then our current logic is not correct.
"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.
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: