On Mon, May 4, 2009 at 3:23 PM, Adam Kocoloski <[email protected]> wrote: > Thanks for the note, Chris. It might be nice if we could figure out a way > not to print "wazzup" N*1000 times when the test suite runs :-) Other than > that, cool! Should make support a good bit easier. >
Yes, that's an interesting side effect of Erlang's dump everything crash reporting. I'm not sure what to do about that, but a more general fix could be handy. Maybe it'd be worth it in this particular case to convert to an exit(normal) after sending the error message out to linked processes. > Adam > > On May 4, 2009, at 6:08 PM, Chris Anderson wrote: > >> Devs, >> >> I'm checking in a patch that should cut down on the number of mailing >> list questions asking why a particular reduce function is hella slow. >> Essentially the patch throws an error if the reduce function return >> value is not at least half the size of the values array that was >> passed in. (The check is skipped if the size is below a fixed amount, >> 200 bytes for now). >> >> I expect this heuristic will need fine tuning. Ideally we'd never >> raise the error on "good" reduces, and always raise it on >> "ill-conceived" ones. If you hit the error on a reduce that seems like >> it should be considered good, please ping the list so we have an >> opportunity to fine-tune. >> >> There is a config option: >> >> [query_server_config] >> reduce_limit = true >> >> changing this to false will revert to the old behavior. Ideally very >> few applications will require this config change, so if you find >> yourself changing this setting, it's a sign you should mail the list. >> >> -- >> Chris Anderson >> http://jchrisa.net >> http://couch.io > > -- Chris Anderson http://jchrisa.net http://couch.io
