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 jason.h.smith@gmail.com
 designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
Sender: jason.h.smith@gmail.com
In-Reply-To: <520DF58D.6040308@gmail.com>
References: 
 <CAPNuaCjQ3wgAd1BMyNUtip0rztK6n3Ex3rnq-hc=NXwL4Wt+pg@mail.gmail.com>
 <CACLy94Uq9eafd_Q-LXV8b3aCipnHgMnaWdn2C1LjnvuMQ-csiA@mail.gmail.com>
 <CAG+HO1zySzJyQMnSj9hfeHVR-XNB2Hpqr97A5ugabvo-wGKdXg@mail.gmail.com>
 <CACLy94XLwHcDyP12igsvCPJ5p46=3=HdoW3xAz_+2RgXH6s=pA@mail.gmail.com>
 <CACLy94Vf6TOz80cM_gWn26nFvMe8A4uQwQNNZQSBRBgYzXB9zg@mail.gmail.com>
 <CAPNuaCiQV2xoDj2O5vg+a-pDzj5ywCwmc+To16ybLeUh4Uc4eA@mail.gmail.com>
 <CACLy94UZtdV+nUUQzoYTiuUP3L=cLy-OjTUC_+6FdBNyAp2fhA@mail.gmail.com>
 <CAPNuaCjavr_udkm_XzO3SMU9gKMfdNnCM1cC71MUQhmtmP5scQ@mail.gmail.com>
 <CACLy94XC=6QFk=FxE+c9Wh41G9C_KosMk8j-tn9-_gia8outRQ@mail.gmail.com>
 <CABvT1DHPsTi=4WwwhTysmZkOda-R6FqsA10NXFyYTUQJR5wGJQ@mail.gmail.com>
 <57E7BFC7-8B8E-4014-8569-B03F99B73E35@apache.org>
 <CAJNb-9okMpQ6Tvxfbia2m_QzT-DVHJ0WfZirPeaHOx6=6TtX3g@mail.gmail.com>
 <520DEB55.8090203@gmail.com>
 <CAJNb-9qqniVvXrmTS2PV5sHvfKBTSHWzb9QHDFxkAgHGZ4+8Jw@mail.gmail.com>
 <CAHdjipJth_AWdfDwqvXrnNsDOhikY0kE-rqWxCmCj__4c5Q6=w@mail.gmail.com>
 <520DF58D.6040308@gmail.com>
From: Jason Smith <jhs@apache.org>
Date: Sat, 17 Aug 2013 02:23:58 +0700
Message-ID: 
 <CACLy94W8+Gt71AUUA1OccCUvYBbpJ2f2stHrEPv1XWdWnP79XQ@mail.gmail.com>
Subject: Re: Erlang vs JavaScript
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Cc: Alexander Shorin <kxepal@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133460076bdd004e415894d

--001a1133460076bdd004e415894d
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 16, 2013 at 4:49 PM, Volker Mische <volker.mische@gmail.com>wrote:

> On 08/16/2013 11:32 AM, Alexander Shorin wrote:
> > On Fri, Aug 16, 2013 at 1:12 PM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> >> I agree, (modulo the fact that I would replace a string by a binary ;)
> but
> >> that would be only possible if we extract the metadata (_id, _rev) from
> the
> >> JSON so couchdb wouldn't have to decode the JSON to get them. Streaming
> >> json would also allows that but since there is no guaranty in the
> >> properties order of a JSON it would be less efficient.
> >
> > What if we split document metadata from document itself?
>

I would like to hear a goal for this effort? What is the definition of
success and failure?

Jan makes a fine point on user@. I "live with the pain." But really, life
is pain. Deny it if you must. Until we are delivered--finally!--our sweet
release, we will necessarily endure pain.

Facts:

* When you store a record, a machine must write that to storage
* If you have an index, a machine must update the index to storage

Building an index requires visiting every document. One way or another, the
entire .couch file is coming off the disk and going through the ringer. One
way or another, every row in the view will be written. I am not clear why
optimizing from N ms/doc to 1/2 N ms/doc will help, when you still have to
read 30GB from storage, and write 30GB back.

One one end the computer scientist says we cannot avoid the necessary time
complexity. On the other end, the casual user says, if it is not
instantaneous, then it hardly matters.

That is, we have a problem of expectation management, not codec speed.
Nobody expects MySQL's CREATE INDEX to finish in a flash, and nobody should
expect that of a view.

If somebody does set out to accelerate views, you're welcome. But I would
ask: what is a successful optimization, and why?

(Also, Noah, if you are out there, this is an example of the sort of thing
I would put on the wiki but past bad experiences make me say "can't be
bothered.")

--001a1133460076bdd004e415894d--