Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.220.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=QSrY341+AddIex6jrywfBXbu7a8yHarxKpJKYyERPaE0POdkkFysA7ducz83VSCefA
         YWo0aOQEVt1wS6lONPbHbyR1EKDQti9e/tpbX4Xml3XpoTnlwGkWqOY/+h9CZzbLyPj5
         xlKOal11wdDlpVAFQFp50PbiXNtCuCopNIqSQ=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=hzoMTchnzBRL1pKMrEYWq633QAA@mail.gmail.com>
References: <5C39FB5A-0ACA-4FF9-BD90-2EBECF271850@apache.org>
 <7939FC32-4118-4B9D-A9D5-12F8EEC220FD@apache.org>
 <BANLkTimbsydyLRvuf6-jhiM36ddh_NSEFQ@mail.gmail.com>
 <6E7AF2B8-3377-416D-8EBE-33664C00FD79@dionne-associates.com>
 <BANLkTi=hzoMTchnzBRL1pKMrEYWq633QAA@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Fri, 24 Jun 2011 13:07:50 -0400
Message-ID: <BANLkTi=XGr16hnkFaO=WRp3ocw7siq12Cg@mail.gmail.com>
Subject: Re: New write performance optimizations coming
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 24, 2011 at 12:59 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Fri, Jun 24, 2011 at 03:36, Robert Dionne
> <dionne@dionne-associates.com> wrote:
>> This is interesting work, I notice some substantial changes to couch_btree, a new query_modify_raw, etc..
>>
>> I'm wondering though if we'd be better off to base these changes on the re factored version of couch_btree that davisp has[1]. I haven't looked at it too closely or tested with it but if I recall the goal was first to achieve
>> a more readable version with identical semantics so that we could then move forward with improvements.
>>
>>
>> [1] https://github.com/davisp/couchdb/commit/37c1c9b4b90f6c0f3c22b75dfb2ae55c8b708ab1
>>
>>
>
> I think the only thing holding that back was a good benchmarking.
> Can we throw these new benchmarks at that branch?
>

The concerns expressed last time were due to the switch to using the
cmp_keys function. I think it was Randall that had the idea to rewrite
the get_node write_node functions to do something in ets to try and
focus in on testing just the btree changes.

I'd also note that I haven't pulled in the recent changes from trunk
that include data sizes and compression into the new branch, so it'll
need a bit of work there as well.