couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <>
Subject Re: [DISCUSS] Mango indexes on FDB
Date Tue, 24 Mar 2020 12:51:17 GMT
On Tue, Mar 24, 2020 at 1:30 AM Joan Touzet <> wrote:

> On 2020-03-23 4:46 p.m., Mike Rhodes wrote:
> > 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.
> I agree.
> > 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.
> Question: Imagine a node that's been offline for a bit and is just
> coming back on. (I'm not 100% sure how this works in FDB land.) If
> there's a (stale) index on disk, and the index is being updated, and the
> index on disk is kind of stale...what happens?

With couchdb_layer this can't happen as each CouchDB node is stateless and
doesn't actually keep any indexes. Everything would be in FoundationDB. So
if the index is built then it is built and ready for all couch_layer nodes.

FoundationDB storage servers could fall behind the Tlogs. I'm not 100% sure
what would happen in this case. But it would be consistent for all
couch_layer nodes.

> -Joan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message