PÁLI Gábor János

@nickva currently, the M/R `complete` message is used as a cue to submit the statistics. If this is not handled properly, it does not matter if there is batching or...

I believe this does not work for short-lived requests. Actually, the real cause of this problem is a race condition: workers often die earlier they could touch the `complete` message...

> I was mainly suggesting a way to have a bound on the uncertainty in the stats, if it the increase in messages is a problem. @nickva I am afraid...

I have done some preliminary [benchmarking with `k6.io`](https://github.com/pgj/couchdb-k6/tree/main/mango/couchdb_4958) on my Apple M1 Max, with 3 nodes (r=2, w=2, q=2), 100K documents, `/{db}/_find` queries of various complexity, 2 minutes warmup and...

> Hmm, if billing is involved then even the current implementation of the PR, will not produce repeatable results unless we're talking about Q=1 databases only. I do not think...

> noting that "billing" of requests is not a couchdb concern. Yes, I agree. But it is CouchDB that could ensure that the data that is going to `chttpd_stats_reporter` could...

Thanks for sharing your thoughts @rnewson. Yes, the execution stats are currently passed around in a dedicated `execution_stats` message but only at the end of the transmission. The other, separate...

I have implemented the half of @rnewson's suggestions and the code is now sending execution stats along with the view rows only. That is still a separate message, but it...

There is an updated version now where the stats are sent along with the row data. Instead of creating a new record type, I switched to using maps and added...

@nickva thanks for the confirmation and the suggestions! I will address them in the other PR about introducing `view_row_map`. I will then rebase this PR to that one and take...