couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: sums by date view
Date Sun, 23 Nov 2008 07:39:26 GMT
On Sat, Nov 22, 2008 at 9:09 PM, Jedediah Smith
<> wrote:
> A possible compromise would be to use group_level to find the balance per
> component and then add those together on the client. Example:
> balance(2008-11-22) =
>  sum(-inf to 2007-) +
>  sum(2008-01- to 2008-10-) +
>  sum(2008-11-01 to 2008-11-22)

This looks like the right way to combine multiple time ranges to me.
Adding on the client is a fine thing in a case like this. However, I
think you can do it in a single query.

> If a view like the
> above existed and I updated an old transaction, there would only be one
> rereduce for each group level, right?

Querying with group=false will be faster, I think. (I should benchmark this...)

In the normal case, with a modest amount of data, that's about right.
Each grouped view query (I think... I really should bust out the log()
in the views to know for sure...) will fire at least one JavaScript
rereduce. In the case of very very much data and a first time reduce
query over that range, the rereduce could run a few times, but the #
of rereduces run should increase only logarithmically with the # of
rows, if I'm not mistaken. It's only when you run multiple queries (or
multple reduces for groups within a range) that you're likely to run
into a linear increase in the number of rereduces. Again, this should
be explored in the log, but I think you'll get a minimum of 1 rereduce
per group query.

The simplest query to get someone's running balance would be something like:

_view/viewname?startkey=["bob", BEGINNING_OF_TIME]&endkey=["bob", CURRENT_DATE]

which has an implicit reduce=true&group=false.

BTW Jan I really like your array date format.

Chris Anderson

View raw message