Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKmKYaB8N0FEDEsGpUGVmj6kD6hStuKyiMxyTT+WHo9y1=UseQ@mail.gmail.com>
References: 
 <CA+Y+447y6kT_kSz-jan89btUG02M=RDpEiKGjJ2gq_p2afTyrQ@mail.gmail.com>
	<CAJNb-9p-AY7n5Qhavis721KHg0yn2y5J0d9jMWN7_VRwWuWmAQ@mail.gmail.com>
	<CAN-3CB+qW-bofvg2hLAmFSnsWaqZBZ2GwiKsztJ=_MDmckk=iw@mail.gmail.com>
	<CABvT1DF1cqxOiHuJtGe11187GHzA47_OW=_pCN+0F5o_7FGEAQ@mail.gmail.com>
	<CAKmKYaCLpPyM6+Vt72KNEdJ_x=jXhUYQfWe7E-1UYfkPSh6fdg@mail.gmail.com>
	<CABvT1DF0SF3od+tq9Fw6982D5OM8RBiUOd_nDQh9CyQx2XS98w@mail.gmail.com>
	<CAKmKYaB8N0FEDEsGpUGVmj6kD6hStuKyiMxyTT+WHo9y1=UseQ@mail.gmail.com>
Date: Fri, 11 May 2012 14:25:13 +0100
Message-ID: 
 <CABvT1DH0-z4_ToQjzmJFUXy-8xPyXg3zn0y32ZvCS4qRT+EanQ@mail.gmail.com>
Subject: Re: Post-mortem
From: Robert Newson <rnewson@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

We're veering off-topic here, but there are several remaining issues.
First is that the view file is at some update_seq relative to the
database file. Being at update_seq N for a view means it has all the
changes up to and including N, but nothing after N, so while those
updates could be processed in parallel, they'd have to be applied to
the view process and view file in order. Secondly, and more
importantly, is how to handle rows that, for whatever reason, cause an
exception when evaluated in the function (e.g, the common case where
there's an undefined property and no guard clause). If the order is
not determined, then two database, with the same data and same view
code, will have different view results for the same input.

I'm not saying it's insoluble, only that it's not as simple as it
might appear at first (or second) glance.

B.

On 11 May 2012 14:04, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> On Fri, May 11, 2012 at 2:44 PM, Robert Newson <rnewson@apache.org> wrote:
>> Fundamentally, the issue is that updating a view is processing an
>> incoming, ordered list of changes, there's not much parallelism to be
>> had there.
>
> Why is that? I don't see how the list of changes is ordered. ISTM that
> updated documents may be passed to the view indexer in any order,
> which is why M/R works. If that's true and computing keys and values
> is CPU-bound, parallelizing running the view function on the updated
> documents shouldn't be that hard.
>
> Cheers,
>
> Dirkjan