> Since the rows I ignore in the reduce should never be updated, maybe they won't be incorporated into future reduce calculations, and thus not cost anything?
They wouldn't cost anything if the data in the old docs wasn't modified. Reduce caches all the reduction values in the b-tree so it will only redo calculations from docs that change. On Sun, Apr 15, 2012 at 12:31 PM, Alon Keren <[email protected]> wrote: > On 15 April 2012 21:06, Mark Hahn <[email protected]> wrote: > > > > would at least reach thousands, so fetching all keys is quite > > demanding > > > > My suggestion may well be the wrong path to take, but I'd like to point > out > > that fetching thousands of keys is nothing. Getting 16 kbytes of data > > takes a few ms. And internally couch has all the keys already sorted > and > > ready to dump when you ask for it. It's not like this 16K is going > across > > the wire to the client. > > > > Latency indeed shouldn't be an issue, but I do wonder about the amount of > CPU my particular scenario would use. > But... > > > > > > I use this kind of query all the time. However, using a reduce would be > > much better. You could keep a list of the ten lowest values found so > far. > > That is a finite amount of data and legal for a reduce. > > > > ...this is an interesting idea. > If I hard-code the limit into the reduce function, perhaps I could indeed > ignore the rest of the rows once I hit it. Since the rows I ignore in the > reduce should never be updated, maybe they won't be incorporated into > future reduce calculations, and thus not cost anything? > Also, how would group-reduce treat this scheme? >
