How much time to generate a view when it does not emit anything?

[Jason Gordon <ja...@assurebridge.com>]

When performing a bulk update, how much time should I expect for view
generation for views that do not index the documents that I am updating?

For example:

I have a single view which is the only view in the design document.  The
view has the map function

if (doc.type == 'Foo') {
    emit(doc.name, doc.age);
  }


and no reduce function.

I then add 8000 documents where doc.type == 'Bar'

When I  access the view the first time , it takes about 7 to 8 seconds to
generate even though nothing is emitted.  Of course, subsequent accesses to
the view are much faster.

I know that I can mitigate by querying the view after adding every couple
of hundred documents but it surprises me that a generate takes this long
when all that is happening is an if-condition being checked.

Is this to be expected or is there a better way to structure the view?

Thanks,

Jason

Re: How much time to generate a view when it does not emit anything?

[Jason Gordon <ja...@assurebridge.com>]

Thanks for the quick reply!

Jason Gordon  | Principal | A S S U R E B R I D G E
Office:  +1 888 409 6995  |  Mobile:  +1 978 885 6102  |  Fax: +1 888 409
6995
Email: jason.gordon@assurebridge.com

On Tue, Jun 20, 2017 at 3:37 PM, Robert Samuel Newson <rn...@apache.org>
wrote:

> Hi Jason,
>
> couchdb has to pass all the updates to the javascript function. There's no
> way to know ahead of time that the function won't call emit.
>
> Each document is marshalled to an external process (couchjs) and the
> response returned, and it's done sequentially (you get parallelism on this
> in couchdb 2.0 though).
>
> B.
>
> > On 20 Jun 2017, at 20:03, Jason Gordon <ja...@assurebridge.com>
> wrote:
> >
> > When performing a bulk update, how much time should I expect for view
> > generation for views that do not index the documents that I am updating?
> >
> > For example:
> >
> > I have a single view which is the only view in the design document.  The
> > view has the map function
> >
> > if (doc.type == 'Foo') {
> >    emit(doc.name, doc.age);
> >  }
> >
> >
> > and no reduce function.
> >
> > I then add 8000 documents where doc.type == 'Bar'
> >
> > When I  access the view the first time , it takes about 7 to 8 seconds to
> > generate even though nothing is emitted.  Of course, subsequent accesses
> to
> > the view are much faster.
> >
> > I know that I can mitigate by querying the view after adding every couple
> > of hundred documents but it surprises me that a generate takes this long
> > when all that is happening is an if-condition being checked.
> >
> > Is this to be expected or is there a better way to structure the view?
> >
> > Thanks,
> >
> > Jason
>
>

Re: How much time to generate a view when it does not emit anything?

[Robert Samuel Newson <rn...@apache.org>]

Hi Jason,

couchdb has to pass all the updates to the javascript function. There's no way to know ahead of time that the function won't call emit.

Each document is marshalled to an external process (couchjs) and the response returned, and it's done sequentially (you get parallelism on this in couchdb 2.0 though).

B.

> On 20 Jun 2017, at 20:03, Jason Gordon <ja...@assurebridge.com> wrote:
> 
> When performing a bulk update, how much time should I expect for view
> generation for views that do not index the documents that I am updating?
> 
> For example:
> 
> I have a single view which is the only view in the design document.  The
> view has the map function
> 
> if (doc.type == 'Foo') {
>    emit(doc.name, doc.age);
>  }
> 
> 
> and no reduce function.
> 
> I then add 8000 documents where doc.type == 'Bar'
> 
> When I  access the view the first time , it takes about 7 to 8 seconds to
> generate even though nothing is emitted.  Of course, subsequent accesses to
> the view are much faster.
> 
> I know that I can mitigate by querying the view after adding every couple
> of hundred documents but it surprises me that a generate takes this long
> when all that is happening is an if-condition being checked.
> 
> Is this to be expected or is there a better way to structure the view?
> 
> Thanks,
> 
> Jason