so crazy? more simple, more stable
2013/8/14 Andrey Kuprianov
> Great! Thanks again.
>
> Andrey
>
>
> On Wed, Aug 14, 2013 at 8:53 PM, Robert Newson wrote:
>
> > Ah, sorry, I missed the nuance. Certainly each design document can use
> > a different view server.
> >
> > B.
> >
> >
> > On 14 Aug
Could anyone offer any tips on ways to optimize the performance of filtered
continuous pull replications? I'm experiencing some slowness pulling data
from my central couchdb to mobile clients. I'm guessing part of the problem
is that my filter contains string manipulation logic (substring
compa
Sorry if this is beating a dead horse.
On Thu, Aug 15, 2013 at 11:37 AM, Jens Alfke wrote:
>
> On Aug 14, 2013, at 8:52 PM, Jason Smith wrote:
>
> > View building time feels important during development but it is
> irrelevant
> > during operation. Production servers never hold up requests to b
On Aug 15, 2013, at 1:09 AM, Robert Newson wrote:
> Off the top of my head, I don't know a safe
> way to evaluate JS in the VM. A NIF-based approach would either be
> quite elaborate or would trip all the scheduling problems that
> long-running NIF's are now notorious for.
Yeah, there could be
1: We accounted for background constant view building before. We're on
cloudant now and have now eliminated that being a source of the lag. In my
tests i've been running on a static database, but is running on our load
testing machine so it's affected by our site load.
2: That's neat, will need to
On Aug 15, 2013, at 11:53 , Benoit Chesneau wrote:
> On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt wrote:
>
>>
>> On Aug 15, 2013, at 10:09 , Robert Newson wrote:
>>
>>> A big +1 to Jason's clarification of "erlang" vs "native". CouchDB
>>> could have shipped an erlang view server that wor
On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt wrote:
>
> On Aug 15, 2013, at 10:09 , Robert Newson wrote:
>
> > A big +1 to Jason's clarification of "erlang" vs "native". CouchDB
> > could have shipped an erlang view server that worked in a separate
> > process and had the stdio overhead, to co
On Aug 15, 2013, at 10:09 , Robert Newson wrote:
> A big +1 to Jason's clarification of "erlang" vs "native". CouchDB
> could have shipped an erlang view server that worked in a separate
> process and had the stdio overhead, to combine the slowness of the
> protocol with the obtuseness of erlang
A big +1 to Jason's clarification of "erlang" vs "native". CouchDB
could have shipped an erlang view server that worked in a separate
process and had the stdio overhead, to combine the slowness of the
protocol with the obtuseness of erlang. ;)
Evaluating Javascript within the erlang VM process int
Yes, to a first approximation, with a native view, CouchDB is basically
running eval() on your code. In my example, I took advantage of this to
build a nonstandard response to satisfy an application. (Instead of a 404,
we sent a designated fallback document body.)
But, if you accumulate the list i
Whoa...OK...that I had no idea about...thanks for taking the time to go to
that granularity, by the way.
So does this mean that the process memory is shared? As apposed to living
in its own space?.so if someone accumulates a large json object in a list
function its chewing up couchdb's memory?...
11 matches
Mail list logo
