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
Choose index based on fields match #469
If two indexes can be used, then instead of choosing the index based on
There is a test that proves the issue and passes based on this fix.
JIRA issue number
For the most part this looks pretty good. Although it doesn't solve the case where we have to choose an index with the same number of columns. Ie, if you have [a, b, c] and [a, d, e] and you have a selector for a.
While I don't want to tack it on as part of this PR, we do have a _count reduce for every view query. In the future we could get fancy and cache selectors and a reduce query with the prefix range and prefer the view that has more documents. Granted that gets complicated and does strange things to latencies when hitting cached vs. not. So basically ignore this paragraph for now and we'll want to pick some other arbitrary metric. The docid thing I think is wrong in hindsight but the only slightly less terrible thing I can think of is using the field names left in the index.
Paul hit the nail for the gist of this, so the only thing I'm going to add is that for the tests, we should probably use the _explain endpoint and make sure we're choosing the right index. So
This got lost:
Idx1 - [a, b, c, d]
and you issued a query with selectors using a,b,c, then we would choose Idx3.
If Idx3 didn't exist, then you need some sort of tiebreaker. The old way used a combination of
You are right that this won't solve the issue when Idx1 is always chosen, and then a new Idx4 [a, b, c, f] which is alphabetically ahead of Idx1is added, then the user could possibly get different results.
Paul did mention:
"In the future we could get fancy and cache selectors and a reduce query with the prefix range and prefer the view that has more documents."
so that we could possibly choose the index with more documents and be a little more consistent. However, it's still probable that some indexes will contain different docs. I'll think about it some more, but do you think that's more of index design on their part?
Generally looks pretty good with some minor style issues. We should also clear up the comments a bit. Took me a good fifteen minutes of contemplating to realize what was going on.