Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rewrite and guard against non-covering queries #3822
The channels and all_docs queries are currently non-covering. For channels this is due to an error in the query statement. all_docs is known to be non-covering, but should be reviewed to identify whether a covering version is possible, due to https://issues.couchbase.com/browse/MB-30467.
Along with fixing the query, we should put in place unit tests that retrieve the EXPLAIN for the query and validate that it's covering (to guard against future regressions).
I noticed that the queries for the Access calls is also not covering and this can cause quite the slowdown. We can make a slight change to the index and not have to modify the query itself and achieve coverage. I have attached the query plans for the non-covering and the covering index.
Here is the current query:
Then we have our current index definition:
And the modified one which is covering:
Let me know your thoughts!
@Binary-Ape The main concern here was the growth in the size of the access/roleAccess index when the full access element is included in the index - particularly when documents are making multiple access grants, this can result in a significant growth to the index size, as the full access element is indexed multiple times per document.
However, I'd be interested in details on the slowdown you've been seeing associated with the non-covering access query. Since the access query only needs to be executed for a given user after a new grant, prioritizing reduced index size over access query speed was judged to be the preferred approach for most use cases. If that's not the case in your deployment, I'd like to hear the details.
@Binary-Ape One additional note - even for the non-covered query, our internal performance testing was still showing the access/roleAccess query performance to be between 2-3x faster than using views, and with more than 10x higher throughput. If you're seeing something different, any information you can share on your usage would be good to hear.