> On Jan 31, 2019, at 12:27 PM, nicholas a. evans <nicholas.ev...@gmail.com> > wrote: > >> I called out the problems with reduce functionality in the first post of >> this thread specifically to shake out people's concerns there, so thank you >> for voicing yours. The current approach to reduce only works because we >> control the writing of the b+tree nodes, including when they're split, etc, >> so we're able to maintain intermediate values on the inner nodes as the data >> changes over time. This is not something we can do with FoundationDB >> directly (or, indeed, anything else). We're looking for a solution here. > > Yes, I don't want to dive too deep into the nitty gritty here (my > experience with FoundationDB is only a quick skim of the docs, > anyway). I was thinking of something along the lines of making a > pseudo-btree (just for reductions, distinct from the map emits) where > each btree node is a FoundationDB value. It might not be useful or > efficient for anything *other* than ranged reduce queries, so perhaps > it could be opt-in per ddoc or per view (and v4.x, where x > 0). It > could be updated within the same transactions as the map emits, or > maybe it could be updated as a cache layer separately from the map > emits.
That’s at least the third time I’ve heard someone independently come up with this idea :) I think it could work, if anyone has the cycles to sit down and write that code. Adam
