couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Mielicki <>
Subject Re: reduce order vs descending
Date Wed, 23 Feb 2011 22:40:40 GMT
2011/2/23 Paul Davis <>:
>>>> For: reduce (null, [key_range_A1_A2, key_range_B1_B2, key_range_C1_C2], true)
>>>> Does the relation A1 < A2 < B1 < B2 < C1 < C2 hold? Does it
depend on
>>>> descending?
>>>> For: reduce ([k1,k2,k3], [v1,v2,v3], false)
>>>> Can I depend on k1 < k2 < k3 if descending=true?
>> However form bird's eye view basing on that one I cannot see a reason
>> not to preserve the first two (in terms of computational complexity
>> even with reduce parallelized). It seems to be only a matter of
>> preserving original b-tree partitioning in parameter passing.
>> Providing such guarantees would be beneficial in two ways:
>> - building a view would not depend on query parameters (sane)
>> - left/right-reduce semantics available (without sorting)

> I don't think any of those things should be guaranteed because that
> means we won't be able to change them at some point in the future if
> the need arises and I can't predict what changes we might need to make
> for various situations.

I have a different opinion on that, mostly because lack of these
guarantees adds overhead in reduce while could be mitigated at
negligible cost (not counting man-month cost of course : ). Not sure
if left/right reduce is unusual scenario in DB. I also think these
guarantees would make view properties consistent and easier to grasp.

> I'm also suddenly wondering how this would behave when run on a
> cluster with the reductions.

That would probably depends on data, but in my case I could allow
somewhat relaxed consistency, thus time based IDs (like
<timestamp|node|seq>) should work across cluster, though I'm sticking
with single node for now. I'm not afraid of data growth as number of
merged fields is limited in my case and I also explicitly trim
(useless) reduce output for excessive key ranges.

Thanks for your time!


View raw message