Re: Map/Reduce View CouchJS Performance

TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0XuF0kpVbF5tm%2FPzDXtLti2k86GKCuRNOwep%2FozI7jA%3Dreserved=0 > >> On 19. Apr 2022, at 13:03, Reddy B. wrote: >> >> Hello, >> >> Is there currently an effort to improve the indexing performance of >> map/reduce

Map/Reduce View CouchJS Performance

Hello, Is there currently an effort to improve the indexing performance of map/reduce javascript views? I have this issue in mind.[https://issues.apache.org/jira/browse/COUCHDB-1743] Improving the indexing performance on very large databases (hundreds of millions of documents) would be

Re: Important update on couchdb's foundationdb work

Hello! Thanks a lot for this update and overview of the situation. As users (our company has been using couchdb since 2015 circa as the main database of our 3 tier web apps), I feel it may be preferable to move the couchdb-fdb work to a separate project having a different name. As Janh has

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

I feel like it could feel weird and inconsistent to introduce a new format here solely to support a third-party tool. Why not add the missing metrics to existing endpoints and let people using prometheus set up an HTTP middleware in the application layer? If there is in built-in support for

Re: [DISCUSS] moving email lists to Discourse

. De : Joan Touzet Envoyé : dimanche 15 mars 2020 19:02 À : dev@couchdb.apache.org Objet : Re: [DISCUSS] moving email lists to Discourse On 2020-03-15 11:02 a.m., Reddy B. wrote: >However, if you are an outsider looking for context that was discussed 2 years >ago

RE: [DISCUSS] moving email lists to Discourse

To add my two cents, I personally engage much more on communities using discourse or some modern Forum engines, than on those relying on mailing lists. As far as browsing archives is concerned, I personally always find it painful to browse email archives to find relevant information. Maybe if

Disable Automatic View Index Warming

Hello, Congratulations for CouchDB 3.0, it truly looks like the best ever CouchDB version! As I was reading the blog series, I immediately got concerned about the automatic View Index Warming feature.

Pay-to-play /Sponsored Features

Hello! We continue to explore with an open mind the various contributions options before us in an effort to find the optimal intersection between risk management, realism and net value to the community (taking into account our unique institutional realities). There is one angle I am curious

Re: Gridfs for CouchDb

erformance at higher cost than the “object store offload” approach. I’m curious why you proposed “attachment” vs. “largeAttachment” as a user-visible distinction? That hadn’t occurred to me personally. Cheers, Adam > On Jul 29, 2019, at 1:43 AM, Reddy B. wrote: > > Hello, > > Mo

Gridfs for CouchDb

Hello, MongoDb has a driver called Gridfs intended to handle large files. Since they have a hard limit of 16mb per document, this driver transparently splits a file in 256kb chunks and then transparently reassembles it upon read. Metadata are stored so they support things such as range queries

Re: CouchDb Rewrite/Fork

. -Joan On 2019-07-10 10:04, Reddy B. wrote: > Of course, this will have nothing to do in terms of branding, I don't even > think we'll use the codebase. Moreover our primarily goal isn't to offer a > competing product to the public. It is to serve our internal needs and reduce >

Re: CouchDb Rewrite/Fork

project and a gentle reminder that you may not call it CouchDB. B. > On 10 Jul 2019, at 00:07, Reddy B. wrote: > > Hi all, > > I've checked the recent discussions and apparently July is the "vision month" > lol. Hopefully this email will not saturate the patience o

CouchDb Rewrite/Fork

Hi all, I've checked the recent discussions and apparently July is the "vision month" lol. Hopefully this email will not saturate the patience of the core team. We have been thinking about forking/rewriting CouchDb internally for quite some time now, and this idea has reached a degree of

RE: [DISCUSS] Proposed Bylaws changes

As a user I would tend to find this safeguard reassuring. For example, when developments such as the FDB branch are happening, this would provide the community additional peace of mind. I too think that the problem addressed by this proposal doesn't exist (yet? ) in this project. I am very

RE: [DISCUSS] : things we need to solve/decide : storing JSON documents

this change. Please continue to follow and contribute to this discussion. B. -- Robert Samuel Newson rnew...@apache.org On Fri, 1 Feb 2019, at 09:11, Reddy B. wrote: > By the way, if the FDB migration was to happen, will CouchDb continue to > be a schema-less database where we can just drop

RE: [DISCUSS] : things we need to solve/decide : storing JSON documents

By the way, if the FDB migration was to happen, will CouchDb continue to be a schema-less database where we can just drop our documents and map/reduce them without further ceremony? I mean for the long-term, is there a commitment to keeping this feature? This is a big deal, the basics of

RE: [DISCUSS] Rebase CouchDB on top of FoundationDB

Hello, Just to add the modest perspective of a user. I appreciate the benefits of taking advantage of the infrastructure provided by FDB both from a quality perspective and from a maintenance and ease of expansion perspective. However, this development makes me really worried of being burned

RE: Insight regarding the strategy with Mango

oc querying and a fair amount easier to learn than ... On Sun, Apr 9, 2017 at 1:07 PM, Reddy B. <redd...@live.fr> wrote: > Hello ! > > > Could someone address this question raising points increasingly intriguing > people : > > > http://stackoverflow.com/questions

Insight regarding the strategy with Mango

Hello ! Could someone address this question raising points increasingly intriguing people : http://stackoverflow.com/questions/40753347/couchdb-mango-performance-vs-map-reduce-views It relates to how Mango works behind the scenes (to avoid performance gotchas), and also asks for

Backup for 2.x

Hi all, The ability to backup as easily as by copying a file was really useful in version 1 as it allowed us to take advantage of a large array of general purpose backup tools. In 2.x, is it safe to just copy the "shards" folder assuming that we intend to "restore" it on a cluster having the

RE: Couchdb views crashing for large documents

t need that data for indexing, it works well. Cheers, Eli On Fri, Nov 25, 2016 at 2:10 AM, Reddy B. <redd...@live.fr> wrote: > > > > I can see that erl.exe actually crashes during the indexing, can someone > please tell me if the dump looks normal ? > > > http

RE: Couchdb views crashing for large documents

on a bombshell, and I'm a bit concerned right now. De : Reddy B. <redd...@live.fr> Envoyé : mercredi 23 novembre 2016 16:06 À : Reddy B.; dev@couchdb.apache.org Objet : Couchdb views crashing for large documents Hello all ! Does somebody have any idea reg

Couchdb views crashing for large documents

Hello all ! Does somebody have any idea regarding the following ? http://stackoverflow.com/questions/40752578/couchdb-views-crashing-for-large-documents I've copied and pasted the question below for easy skimming : up votedown

Re: CouchDB Next

omposable approach, where you could assemble a system of couchdb components and custom components? It might help at this point to hear some more examples of the extensions you didn't feel able to make. B. On 28 Sep 2016, at 13:04, Reddy B. <redd...@live.fr> wrote: I've been very busy with wor

Re: CouchDB Next

details of that distract from the intention here. What you seek is a more composable approach, where you could assemble a system of couchdb components and custom components? It might help at this point to hear some more examples of the extensions you didn't feel able to make. B. On 28 Sep 2016, at 13

Re: CouchDB Next

I've been very busy with work for one month only and when I catch up 2.0 is out and you're even talking about 3.0, congratulations. I'd like to contribute to this list, I've not read the source code of CouchDb yet so I can't be too precise but as the head of development of several companies,

Re: CouchDB 2.0 blog series

them done by the 13th of August :) On 20/07/2016 17:42, Jenn Turner wrote: Thanks Reddy! I will add these to the list. Were you interested in writing up either topic? On Tue, Jul 19, 2016 at 3:16 PM, Reddy B. <redd...@live.fr> wrote: Hi Jenn, Just to share two topics ideas for the

Re: CouchDB 2.0 blog series

Hi Jenn, Just to share two topics ideas for the Migration Guide : - it would be great to have a guide focused on moving from a single node CouchDb 1.6.x to a distributed cluster using 2.0 features. As a 1.6.x user, this is the biggest quotation mark - and excitement I have. I wouldn't feel

RE: 154 million voter records

Yea that's the only positive... Now the nasty thing would be to add them to the CouchDb in the Wild Page. Even though it's literally in the wild here > From: kxe...@gmail.com > Date: Thu, 23 Jun 2016 16:49:42 +0300 > Subject: Re: 154 million voter records > To: dev@couchdb.apache.org > >

Re: 2.0 & Windows: status update

Regarding the quote below, I just wanted to mention that this is indeed how we use CouchDb here : as a production database on Windows Server. We both develop on Windows and host on Windows. The first-class support and stability of CouchDb on the platform largely contributed to our interest in

RE: Post on Trigger

ou can make it > more clear to me what you especially want to reach? > > Cheers, > Harry > > On Thu, May 19, 2016 at 1:49 PM, Reddy B. <redd...@live.fr> wrote: > > > Hi, > > > > I am fairly new to CouchDb and loving it so far. I think this database is > &g