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
At present, our property pruning optimization only considers the symbols between operators without analyzing specific expressions, so some statements that can be optimized may be ignored. The following statement can prune all properties.
MATCH (v1)-[e:like*1..5]->(v2)
WHERE id(v1) == "Tim Duncan"
RETURN count(v2)
This optimization can not only reduce rpc overhead but also reduce memory pressure during graphd computation.
The text was updated successfully, but these errors were encountered:
Fwiw, some simple aggregations like count(*) can be considered pushed down to the storage layer(Scan or Traverse operator).
This may greatly improve the performance of statements like the above.
At present, our property pruning optimization only considers the symbols between operators without analyzing specific expressions, so some statements that can be optimized may be ignored. The following statement can prune all properties.
This optimization can not only reduce rpc overhead but also reduce memory pressure during graphd computation.
The text was updated successfully, but these errors were encountered: