Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <14457E59-A9FC-457B-BE11-EBC431E4D7C5@sri.com>
References: <C61F81C5-DE7B-4C32-BC56-799D8548A761@thenoi.se>
	<14457E59-A9FC-457B-BE11-EBC431E4D7C5@sri.com>
Date: Wed, 4 Jan 2012 23:18:05 +0000
Message-ID: 
 <CABvT1DEvsHBcUOg-kDT0aX06_dixUUyQAD6N-K0H8Jc6kwhdJw@mail.gmail.com>
Subject: Re: View generation order.
From: Robert Newson <rnewson@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Martin,

In answer to your actual question: No, it is not currently possible to
ask couchdb to build view over just the most recent N
documents/updates in a database.

It's true that separating views into different design documents will
allow parallel view building but note that too much parallelism is
just as much as problem as too little.

B.

On 4 January 2012 23:07, Jim Klo <jim.klo@sri.com> wrote:
> What we've done, which may not be ideal... but in our app, all view queri=
es are stale (will be migrating to stale and update once we upgrade couchdb=
), but then have an external job that triggers the indexing by querying for=
 1 element in a view in each design doc. =A0You could follow a similar appr=
oach and prioritize which indexes start indexing first if you have resource=
 limitations, otherwise, I think indexing multiple design docs is concurren=
t.
>
>
> Jim Klo
> Senior Software Engineer
> Center for Software Engineering
> SRI International
>
>
>
>
> On Jan 4, 2012, at 2:50 PM, Martin Hewitt wrote:
>
>> Hi all,
>>
>> I was wondering if it's possible to set or influence where the view gene=
ration process starts?
>>
>> We have a large DB which we let clients build views on. We then map thos=
e views to JS map functions and create the relevant design doc. The only pr=
oblem we have is that the database is huge and the view generations take a =
while. This means the oldest data is processed first, which doesn't suit us=
 as, in the short term, the most useful values are those which are more rec=
ent, i.e. the entries that were made a minute ago not a year ago.
>>
>> Any help gratefully appreciated.
>>
>> Martin
>