incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: View Filter
Date Fri, 15 May 2009 10:13:31 GMT

On 14 May 2009, at 16:53, Zachary Zolton wrote:

> Please reiterate, Brian. I'm not quite sure what you're getting at  
> here:
>
> (1) people who are storing large documents in CouchDB but not  
> indexing them
> at all (I guess this is possible, e.g. if the doc ids are well-known  
> or
> stored in other documents, but this isn't the most common way of  
> working)
>
>
> I do agree, though, that only being able to filter at the design doc
> level limits the utility of view filtering. Given that a design doc is
> supposed to be an application's "view" of the database, would we want
> to encourage folks to make a different design doc for each type of
> data they store in the database?

No! :) The patch is only meant for "post-application". I.e. you create
views and design docs as it makes sense for your application and
then if, and only if, you end up in a situation where this patch gives
you speed, you use it. I don't want to encourage a "one view per
design doc" setup.


> My gut says "one design doc per
> application" —but I could be all mixed up!

Your gut is correct ;) But some apps might need more than one
design doc.

Cheers
Jan
--



>
> Cheers,
> Zach
>
>
> On Thu, May 14, 2009 at 2:43 AM, Brian Candler <B.Candler@pobox.com>  
> wrote:
>> On Wed, May 13, 2009 at 09:41:29AM -0500, Zachary Zolton wrote:
>>> So, this sounds like a big win for those who like to store many
>>> document types in the same database with a "type descriminator"  
>>> field.
>>
>> ... but only if all views in the same design doc are filtered by  
>> the same
>> set of types. That is, you can only use it to exclude documents  
>> which are
>> not used by *any* view. Therefore the benefit is for:
>>
>> (1) people who are storing large documents in CouchDB but not  
>> indexing them
>> at all (I guess this is possible, e.g. if the doc ids are well- 
>> known or
>> stored in other documents, but this isn't the most common way of  
>> working)
>>
>> (2) people who have a separate design document for each "type" of  
>> object.
>> They would most likely get the same or better performance benefit  
>> by having
>> a single design document with all their views.
>>
>> I also think there are other pinch-points in view generation which  
>> need
>> working on, although perhaps they are not as quick wins as this one.
>>
>> For example, on my old Thinkpad X30 (mobile P3 1.2GHz), I can  
>> insert a set
>> of 1300 documents in ~2 secs using _bulk_docs. However the first view
>> request (generating ~6000 keys) takes around 35 seconds to respond.
>>
>> Regards,
>>
>> Brian.
>>
>


Mime
View raw message