Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_i+1wccqF7h16sVtFsmIGkw)"
From: Jim Klo <jim.klo@sri.com>
Subject: Re: View generation order.
Date: Wed, 04 Jan 2012 15:07:12 -0800
In-reply-to: <C61F81C5-DE7B-4C32-BC56-799D8548A761@thenoi.se>
To: user@couchdb.apache.org
References: <C61F81C5-DE7B-4C32-BC56-799D8548A761@thenoi.se>
Message-id: <14457E59-A9FC-457B-BE11-EBC431E4D7C5@sri.com>

--Boundary_(ID_i+1wccqF7h16sVtFsmIGkw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

What we've done, which may not be ideal... but in our app, all view queries 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.  You could follow a similar approach and prioritize which indexes start indexing first if you have resource limitations, otherwise, I think indexing multiple design docs is concurrent.


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 generation process starts? 
> 
> We have a large DB which we let clients build views on. We then map those views to JS map functions and create the relevant design doc. The only problem 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 recent, i.e. the entries that were made a minute ago not a year ago. 
> 
> Any help gratefully appreciated. 
> 
> Martin


--Boundary_(ID_i+1wccqF7h16sVtFsmIGkw)--