Heya Reddy, there are no current plans to improve indexing performance by revising the couchjs protocol.
CouchDB gives you these options to speed up indexing, especially larger databases: - increase the q value of your database[1]. Shard indexes are built in parallel and this scales linearly with available CPU cores. - switch to Mango where possible. Mango is less expressive than views, so not all can be migrated. There is some light movement in making mango more expressive, but nothing definite is available at the moment[2]. Finally, the CouchDB+FDB codebase includes a variant of views where indexes are updated on write instead of on-read. I hope that this design, at least as an opt-in features, makes its way to mainline CouchDB. Then you can trade-off doc write time with index-build time. Given the nature of the couchjs implementation, I don’t see a lot of room for substantially revamping the couchjs protocol. If we ever move to something that gives us a more fully fledged programming environment, there are further options. Best Jan — [1]: https://docs.couchdb.org/en/3.2.2/cluster/sharding.html#splitting-shards [2]: https://github.com/apache/couchdb/pull/3912 — Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/ 24/7 Observation for your CouchDB Instances: https://opservatory.app > On 19. Apr 2022, at 13:03, Reddy B. <redd...@live.fr> wrote: > > Hello, > > Is there currently an effort to improve the indexing performance of > map/reduce javascript views? I have this issue in > mind.[https://issues.apache.org/jira/browse/COUCHDB-1743] > > Improving the indexing performance on very large databases (hundreds of > millions of documents) would be strategic. > > What is the current consensus on this question? have a decision been made > that users should use mango moving forward, or would work related to the > proposal brought in the aforementionned issue be welcome? > > Best, > > Reddy
