couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: svn commit: r815404 - /couchdb/branches/0.10.x/etc/couchdb/
Date Tue, 15 Sep 2009 22:54:19 GMT

On 15 Sep 2009, at 20:30, Chris Anderson wrote:

> On Tue, Sep 15, 2009 at 10:22 AM, Jan Lehnardt <> wrote:
>> On 15 Sep 2009, at 19:09, wrote:
>>> Author: jchris
>>> Date: Tue Sep 15 17:09:22 2009
>>> New Revision: 815404
>>> URL:
>>> Log:
>>> changed default for 0.10 to delayed_commits = true for fast out of  
>>> box
>>> experience
>> Chris, please discuss this first on dev@.
> Sorry about that - just having a strong gut reaction to the potential
> of releasing 0.10 that's too slow to use.
> Good thing is that this commit got everyone talking on IRC.
> The basic tradeoff here is between safety and speed. With a simple
> benchmark on my Mac laptop (OSX 10.5) delayed_commits gives ~230
> writes/second while we only get about 5/sec with the slow safe option.
> I think 5 writes/second is too slow to be useful, so it doesn't matter
> how safe it is.

I think we need to define use-cases a bit more clearly and then try to
determine how much safety we can and want to guarantee. I'd like to
avoid situations where we send a Created 201 response when that
doc is still in limbo and CouchDB could do extra work to make sure
it is on disk.

I especially don't want to enable delayed commits by default for simple
speed-freak reasons. CouchDB could easily detect long running fsync()s
and send a log entry about enabling delayed commits. Proper  
& release notes will help too. Finally, there will always be people  
CouchDB has whatever properties (slow, fast, green) they see fit*.

If we want to bill CouchDB as everybody's personal database, we better
keep that personal data safe :)

* See Postgres.

View raw message