On Fri, May 11, 2012 at 2:44 PM, Robert Newson <[email protected]> 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

Reply via email to