On Jan 13, 2010, at 3:37 PM, Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Anderson wrote: >>> The ticketing system should be for smaller scope issues, I think. > > I see it more as a "don't forget about this" plus somewhere for others to > say "this also affects me" or "here is additional information/angles". > Obviously there is a fine line between that kind of thing and a discussion. > My big concern is that the issue was hashed out here over a few days then > the thread goes dead, and the issue is forgotten. A JIRA report of open > issues should be a todo list of bugs to fix and improvements to make.
That's fine, the issue is that bugs saying "It's too slow" is always true for someone. Many people find the view indexing performance just fine, many do not. Since CouchDB makes no performance or size guarantees, you can't call the general performance a bug. Unless you have specific bug to fix, or enhancement to make, don't use JIRA. Use the dev mailing list to make your case, see if someone will produce a patch or find a measurable bottleneck that can be addressed. JIRA is not the place for discussions about the design of CouchDB components. Neither is IRC. Also, if you want something without view performance problems but similar to CouchDB, you should look at MongoDB. -Damien > >>> Optimizing the view server is an agreed goal of the community. > > Maybe in people's heads, but it wasn't written down anywhere such as the > tracker or the roadmap. In fact the front page of couchdb.org claims that > Erlang allows for the CouchDB design to be scalable and the overview page > makes an "efficient" claim in the last sentence. The current implementation > is neither of these. > >>> Probably the best way to help is to take a look at all the work >>> Damien's done in trunk (the pipelining) and perhaps the parallel >>> writers optimization he has. > > BTW I have been using trunk for over a week. It is better than 0.10 that I > was using before but not that much of an improvement. And changes in the > way I generate some of my data have hurt me again (I can either order for > _id or for view keys but not both at the same time) so my initial DB has now > gone from 4GB to 15GB (I optimized for views). > >>> We could really use a way to take the >>> benchmarks you ran, and put them into the buildbot. > > Sadly I can't do it with my real data because it belongs to someone else. > However I hereby commit to produce a representative benchmark that is > substantially similar in performance and data within the next two weeks. > (Also note that there is nothing special about what I am doing - anyone with > similar numbers of documents has similar issues.) > > I'm hoping that more can be done about the size issues soon too. (I think > that addressing the size issues will help a lot since it will require way > less CPU and I/O to produce and use smaller files.) > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktOWSgACgkQmOOfHg372QQ9rQCfTiSs1etiafvG1z4q1yQC0ZRy > +3AAn0j2TEPuW/AXTvNZl9KPfTT6hGNn > =rSWg > -----END PGP SIGNATURE----- >
