Garren, Very much +1 on this suggestion, as it is, at least for me, what I'd expect to happen if I were leaving the system to select an index -- as you imply, the build process almost certainly takes longer than using the _all_docs index. In addition, for the common case where there is a less optimal but still useful index available, one might expect that index to be used in preference to the "better" but unbuilt one.
But I do think this is important: > We can amend the warning message > to let them know that they have an index that is building that could > service the index when it's ready. Otherwise it's a bit too easy to get confused when trying to understand the reason why an index you were _sure_ should've been used in fact was not. -- Mike. On Mon, 23 Mar 2020, at 17:27, Garren Smith wrote: > Hi Everyone, > > Currently with Mango, when selecting an index to service a query, Mango > does not take into consideration whether the index is fully built or not. > This can lead to unexpected response times when a new index is created. It > also makes it really tricky on how to deploy a new index into a large > production database because any new index could cause large delays to > queries. > > For Mango indexes on FoundationDB, I would like to change the behavior so > that only indexes that are built can be used to service query requests. The > reason we can make this change is that Mango indexes are built slightly > differently on FDB. When an index is created, an initial background process > will build the index up the change seq that the index was created. At the > same time, any new doc updates are immediately indexed in the document > transaction. > So for Mango on FDB, what I want to do is not choose any index that still > has the background process doing the initial build. > > This is a bit of a user experience change. The one area where it would be a > noticeable change is if a user creates their first index in a database, and > then does a query. If the index is not built yet, Mango would use _all_docs > to service the query and return a warning that they have no index. This > could definitely be confusing for a user. We can amend the warning message > to let them know that they have an index that is building that could > service the index when it's ready. > > I really like the idea of not using indexes that are still building. It > allows the user not to have to worry and think about managing indexes. They > can add an index, and keep querying. It the current query is a bit slow, it > will start getting faster once the newer better index is ready. But it will > never get slower because we selected an index that is going to take 30mins > to build. > > I would like to know if you would prefer that we remove indexes that are > being built from selection for queries or would you like it to remain the > same as in CouchDB 3.x > > Cheers > Garren >
