Hi all,
For once, I’m coming to you with a topic that is not strictly about
FoundationDB :)
CouchDB offers a few config settings (some of them undocumented) to put a limit
on how long the server is allowed to take to generate a response. The trouble
with many of these timeouts is that, when
I could certainly see handling `emit(key, doc)` as a special case. I would feel
even better pursuing that special-case handling if we could characterize the
performance delta between a) executing the first range operation on the view
index + N additional range operations in paralle to retrieve
Thanks Garren,
As usual, a few questions :)
1. The data model suggests the idea of view groups gets carried over to
fdb. Are there API / behaviour reasons to keep them? Would an index update
transaction scope to a view group rather than a single view?
2. Regarding emitting doc as the value in a
Hi Everyone,
I want to start a discussion around creating map/reduce view indexes. One
way to get views indexes to work with FoundationDB is to break up a view
index into indexes for the map functions and indexes for the reduce
functions. Along those lines, I’m going to break the discussions into
Hi Alex,
Thanks for the really detailed explanation on transaction size calculation.
That is really helpful. Adding a limit to number of indexes is a good idea.
Cheers
Garren
On Fri, Apr 12, 2019 at 3:58 AM Alex Miller
wrote:
> There was some discussion on the FDB forums previously about how
