On Thursday, August 15, 2013, Andrey Kuprianov wrote: > Doesnt server performance downgrade, while views are being rebuilt? So the > faster they are rebuilt, the better for you.
If my view build would degrade total performance to cross an unacceptable threshold, then I am really riding the line! What about an unplanned compaction? What if one day the clients have a bug and load increases? What if an unplanned disaster happens and a backup must be performed urgently? I would evaluate view performance in the larger context of the entire application life cycle. Men seem to want to date beautiful women. It is a very high priority at the pub or whatever. But long-married men do not even think about their wife's attractiveness because that is a small, superficial part of a much larger story. > > Besides, looks like it's possible to do the same 3 steps with design doc > views created in Erlang? Or is it just about using require() in Node.js? > Actually, yes that is a fine point. I myself prefer Node.js but anyone can choose the best fit for them. And speaking more broadly, CouchDB is a very flexible platform so it is quite likely that my own policies do not apply to every use case. In fact if I'm honest I use native views myself, usually for unplanned troubleshooting, I want to find conflicts so I use manage_couchdb: http://github.com/iriscouch/manage_couchdb My main point is, anybody time somebody says "performance" ask yourself if it is really a "performance siren." Earlier in this thread, Jens raises some examples of plausible true performance requirements, not just siren songs.
