Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of djc.ochtman@gmail.com
 designates 74.125.82.180 as permitted sender)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
In-Reply-To: 
 <CAJNb-9p-AY7n5Qhavis721KHg0yn2y5J0d9jMWN7_VRwWuWmAQ@mail.gmail.com>
References: 
 <CA+Y+447y6kT_kSz-jan89btUG02M=RDpEiKGjJ2gq_p2afTyrQ@mail.gmail.com>
 <CAJNb-9p-AY7n5Qhavis721KHg0yn2y5J0d9jMWN7_VRwWuWmAQ@mail.gmail.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Fri, 11 May 2012 08:55:32 +0200
Message-ID: 
 <CAKmKYaDYUHs4NJQsEsXo1Y3huYju50tEkSxSuWMvAwGbnSY-VQ@mail.gmail.com>
Subject: Re: Post-mortem
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Fri, May 11, 2012 at 7:56 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> Anyway, Imo we need to improve some feature like M/R (having the
> indexation using multiple cores), replication ,and possibilities to
> monitor what happen in every part of couch.

+many. We have this wonderfully scalable algorithm to do the view
indexing, and then it's only used with 1 thread at a time! I've never
really understood why that is (even though I understand that the
algorithm being scalable doesn't help with serializing things on disk
and whatever else).

Also, a mode that will update all the indexes (asynchronously) on
insertion/updates would probably be something we'd use. It seems to me
Couch is better at read-heavy loads than at write-heavy loads, yet the
index-on-access seems optimized for the latter!

Cheers,

Dirkjan