Hi, Sorry.
The global database schema is well designed and the database should compact down very neatly, so be sure you _are_ compacting it regularly. If it's still a problem, just delete it, it's completely optional. Obviously you lose the /_db_updates feature without the backing store, but everything else works. B. > On 5 Jul 2017, at 23:47, Vladimir Kuznetsov <vova...@gmail.com> wrote: > > Hi guys, > > Can somebody please answer this? > > thanks > --Vovan > >> On Jun 29, 2017, at 3:37 PM, Vladimir Kuznetsov <vova...@gmail.com> wrote: >> >> Hi guys, >> >> Can somebody please answer this? I'd really appreciate If somebody could >> provide any good pointer to the documentation about _global_changes >> internals. I think it'd be useful for many people. Basic answers like at >> what circumstances _global_changes is being updated(I noticed it's not >> always updated on document insert), does it provide any expiration or >> self-management capabilities to get it's size under control, any other >> things to keep in mind... >> >> thanks, >> --Vovan >> >> >>> On Jun 27, 2017, at 1:09 PM, Vladimir Kuznetsov <vova...@gmail.com> wrote: >>> >>> Hi guys, >>> >>> I have thousands of databases in Couchdb 2 cluster and I get them >>> constantly updated. Each database is also rotated on monthly basis i.e. I'm >>> keeping dbs for the last several months, then just remove oldes ones. I >>> suppose _global_changes database is going to extensively grow as databases >>> are going to be continuously created/updated/deleted. Does _global_changes >>> database provide any mechanism of automatic data expiration? Or is it >>> better to disable _global_changes database with such a usage pattern? >>> >>> thanks, >>> --Vovan >> >
