couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Nevile" <...@mainsocial.com>
Subject Re: Efficient view design question
Date Mon, 27 Oct 2008 20:48:33 GMT
Hi Chris - thanks for the update=true.  ;)
For highly-interdependent data sets this feature is really important.  I'll
follow your progress closely, and be happy to test out on my real data
(hundreds of thousands of records, millions of writes a day.)

Ben


On Mon, Oct 27, 2008 at 1:36 PM, Chris Anderson <jchris@apache.org> wrote:

> On Mon, Oct 27, 2008 at 10:51 AM, Ben Nevile <ben@mainsocial.com> wrote:
> > Thanks Jason.  One further clarification, re "If you set the *update*
> option
> > to*false*, CouchDB will not perform any refreshing on the view that may
> be
> > necessary."
> > Does this mean that if I only call the view with update=false, the view
> > index will never be updated?
> >
> > Ben
>
> The update=false behavior is complicated by some implementation
> details. Oh, and the feature is currently not available in trunk, but
> is under active development.
>
> The upshot is that update=false will be useful for reducing latency in
> queries against a database that has a lot of writes going into it.
> However, it's not a guarantee that the no updating will be triggered,
> nor does it guarantee that results will be returned immediately. For
> that reason, the name might be misleading, but let's wait til the
> implementation is done to reconsider the name.
>
> Implementation details: update=false queries the latest available
> version of a completed view index. This means that if the view has not
> been built yet, there will not be an available completed index, and
> the index will be built before running the query. Also, in the case of
> a freshly booted server, there may not be a pointer to the last
> completed index, so we end up running an update then as well. For
> various reasons, partially completed indexes are not viable for
> queries.
>
> There are a lot of people who'd like a progress-bar on view
> computation. It is possible that we'll make available something like
> update=status, which could tell users roughly how many docs have been
> mapped, vs how many docs there are total, which would give an
> approximate measure of progress.
>
> Chris
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message