couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <zachary.zol...@gmail.com>
Subject Re: View Filter
Date Thu, 14 May 2009 14:53:14 GMT
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? My gut says "one design doc per
application" —but I could be all mixed up!

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