Indeed puzzling.
If you delete the database (DELETE /dbname) and if this succeeds (2xx response)
then all of the db data is deleted fully. If you think you're seeing data
persisting after deletion you have a problem (the delete is failing, or you're
not really deleting the db, or something extr
Hi Willem,
Good question. CouchDB has a 100% copy-on-write storage engine, including for
all updates to btree nodes, etc. so any updates to the database will
necessarily increase the file size before compaction. Looking at your info I
don’t see a heavy source of updates, so it is a little puzzl
Hi Adam,
I ran "POST compact" on the DB mentioned in my post and 'disk_size' went
from 729884227 (yes, it had grown that much in 1 hour !?) to 1275480.
Wow.
I disabled compacting because I thought it was useless in our case since
the db's and the docs are so small. I do wonder how it is possible
Hi Willem,
Compaction would certainly reduce your storage space. You have such a small
number of documents in these databases that it would be a fast operation. Did
you try it and run into issues?
Changing cluster.q shouldn’t affect the overall storage consumption.
Adam
> On May 2, 2019, at
