2011/2/23 Paul Davis <[email protected]>: >>>> 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! Łukasz
