-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
perf(core): add index on name #44586
Conversation
339e83c
to
37f4708
Compare
Signed-off-by: Varun Patil <varunpatil@ucla.edu>
37f4708
to
5bb0a29
Compare
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.
LGTM - and this is a really useful and impactful contribution too! Thank you so much :)
If the index is only required for this kind of query (with |
I wouldn't say it's the only potential use case for the index but doing a scan beyond 12 characters is not a big deal anyway, so I don't mind. |
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! |
We already have an index on parent+name but this can't be used for filtering just by name in a user's root. Such a query is used by both Photos and Memories for filtering out nomedia files.
(this is on a smallish filecache with 400k; it gets pretty slow when the filecache can't fit into memory cause it's doing a scan)
Query looks like this:
Query plan BEFORE:
AFTER:
Note: it might possible to create a joint index that's even faster but this index might help the optimizer with other unrelated queries so I think this is better.