-
Notifications
You must be signed in to change notification settings - Fork 64
fix SHORTEST queries #1388
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
fix SHORTEST queries #1388
Conversation
| ---- | ||
| The result is a significantly faster query (down from 59 to 9 milliseconds): | ||
| The result is a less resource intensive query: |
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.
Is the drop in execution time not worth mentioning?
| This constraint will inform the planner of the uniqueness of `trail` values up front. | ||
| As a result, the simpler shortest path query (without a `CALL` subquery) will now generate a faster plan (using the `StatefulShortestPath(Into)`) operator with a cardinality of 1 for both the source and target nodes of the shortest path. | ||
| As a result, the simpler shortest path query (without a `CALL` subquery) will now generate a faster plan (using the `ShortestPath` operator) with a cardinality of 1 for both the source and target nodes of the shortest path. |
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.
OK I didn't realise that both queries are planned as ShortestPath. So there is no example where SSP(Into) improves performance. I think we need that. The simplest thing to do would be to change the quantifier to {2,}.
dogofbrian
left a comment
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.
🎉
|
Thanks for the documentation updates. The preview documentation has now been torn down - reopening this PR will republish it. |
No description provided.