couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: svn commit: r804427 - in /couchdb/trunk: etc/couchdb/ share/www/script/test/delayed_commits.js src/couchdb/couch_db.erl src/couchdb/couch_httpd_db.erl
Date Sat, 15 Aug 2009 16:45:33 GMT
On Aug 15, 2009, at 11:43 AM, Chris Anderson wrote:

> On Fri, Aug 14, 2009 at 6:55 PM, <> wrote:
>> Author: kocolosk
>> Date: Sat Aug 15 01:55:32 2009
>> New Revision: 804427
>> URL:
>> Log:
>> delayed commits are now a config option, off by default. Closes  
>> COUCHDB-449
> I understand the value of this, but I'm not sure about whether it's
> the best way to greet new users. In informal benchmarks just now,
> delayed_commits makes CouchDB more than twice as fast. With
> delayed_commits=true, hovercraft:lightning() does 100k docs in just
> under 10 seconds. With the new default, it takes roughly 25 seconds.

And of course the problem will be much worse for anyone doing user- 
friendly PUTs instead of _bulk_docs.

> We had this discussion once before, and came down on the side of speed
> - what made us change our mind?

In fact I don't know that we ever really did discuss what the default  
ought to be.  When Damien added the feature he said [1]
> Right now the default is to delay the commits, because I think that  
> will be the most common use case but I'm really not sure. I  
> definitely want the commits delayed for the test suite, to keep  
> things running fast.

but the rest of the thread dealt with the precise guarantees of the  
fsync() and fcntl(F_FULLFSYNC) calls. No one talked about the default,  
but in COUCHDB-449 all votes were for safety first.

I believe we should try really hard not to lose users' data.  With  
delayed_commits = true our durability story is basically the same as  
Redis'.  I think that would be surprising to most new users.  Best,



View raw message