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 <[email protected]>
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.
