On 6 Apr 2010, at 10:23, Julian Moritz wrote:

> Hi,
> 
> first of all: to make the keys of a view unique via reduce, i do it as
> it's desribed in the "definitive guide to couchdb".

try using "_sum" as your reduce function, it'll use an Erlang version that
will be faster than the JS version. "_sum" expects the emit() value to be
an integer. Just emit(doc.whatever, 1).

Cheers
Jan
--

> 
> J Chris Anderson schrieb:
>> On Apr 5, 2010, at 12:19 PM, Julian Moritz wrote:
>> 
>>> But I need it for making my list unique. This is an important feature
>>> for my application.
>> 
>> This is probably explains the slowness. When you do a group=true query, CouchDB has to run the reduce function once for each unique key (serializing all the rows in the key to the JS process, and parsing the results.)
>> 
>> I haven't tested this, but you might get better response throughput by dropping the reduce function and using a _list which only sends one row of output each time the key changes. This will avoid some additional Erlang processing of the result.
>> 
>> Some documentation for _list is here:
>> 
>> http://books.couchdb.org/relax/design-documents/lists
> 
> Thank you, I will have a look on it.
> 
> Regards
> Julian
> 
>> 
>>> Thanks, I'll think about how to set up a couchdb cluster and do more
>>> testing.
>>> 
>>> Regards
>>> Julian
>>> 
>>>> Chris
>>>> 
>>>> 
>>>>> Regards
>>>>> Julian
>>>>> 
>>>>>> I've developed a (in my eyes) simple view. I have a wordlist which does
>>>>>> not  contain unique words. I want to store it in a view, with every word
>>>>>> occurring once and ordered by random. Therefore I have a simple view
>>>>>> function:
>>>>>> 
>>>>>> function(doc){
>>>>>> emit([hash(doc.word), doc.word], null);
>>>>>> }
>>>>>> 
>>>>>> and a simple reduce:
>>>>>> 
>>>>>> function(key, values, rereduce){
>>>>>> return true;
>>>>>> }
>>>>>> 
>>>>>> calling that view with group=true it does what I want.
>>>>>> 
>>>>>> When storing plenty of words to the database, one of my two cpu cores is
>>>>>> used completely by couchjs.
>>>>>> 
>>>>>> Isn't the view built using two (or all) cpu cores? I thought (obviously
>>>>>> I'm wrong) that it would be calculated in parallel and using a
>>>>>> quadro-core (or more cores) would make storing faster.
>>>>>> 
>>>>>> Is there a solution for that? Should I use another query-server?
>>>>>> 
>>>>>> Regards
>>>>>> Julian
>>>>>> 
>>>> 
>> 
>>