-
Notifications
You must be signed in to change notification settings - Fork 103
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
[master < T1227] Optimise iteration #1227
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
1fa7535
to
9c6e202
Compare
Query like: UNWIND RANGE (1, 500) AS i CREATE (); MATCH (),(),() RETURN COUNT(*); went from 6.549 sec to 3.625 sec
9c6e202
to
ccb70dd
Compare
@vpavicic this probably requires a bit more attention in the changelog because it's a significant improvement (100%) in the case where there is a lot of iterations over graph entities, the query @Ignition put into the description is just one example, but I think this optimization applies in many cases 👀 @Ignition maybe you can add a bit more details from the user perspective (e.g. what's the real world query that will benefit out of this) 😃 |
@Ignition Do you have any more queries to show the usage/benefits? |
@vpavicic not really, the query I optimized around demonstrated ScanAll performance gain. But I expect real usecase would be more complex. Hence IMO other parts of the plan would dominate the execution profile. |
For example following query:
went from
6.549
seconds to3.625
secondsTo keep docs changelog up to date, one more thing to do: