"In Futon, my gwibber_messages database is reported to be 90MB with roughly 12,000 messages. When I compact it, the size drops to about 20MB. Periodically compacting the db would certainly help."
What couchdb-replication sends over the wire, are individual documents, and not the entire db. Compaction has no impact on replication traffic, as it gets rid of old versions of documents, which are never replicated. (What's being sent is any documents with changes since the last successful replication.)
.gwibber_messages_design contains stored view indexes, which are (re)computed on each node when they are called, and so also never sent over the wire.
So, while periodic compaction is a very good idea to save disk space, it will not have an effect on repliction.
In reply to:
"37M .gwibber_ messages_ design"
and:
"In Futon, my gwibber_messages database is reported to be 90MB with roughly 12,000 messages. When I compact it, the size drops to about 20MB. Periodically compacting the db would certainly help."
What couchdb-replication sends over the wire, are individual documents, and not the entire db. Compaction has no impact on replication traffic, as it gets rid of old versions of documents, which are never replicated. (What's being sent is any documents with changes since the last successful replication.)
.gwibber_ messages_ design contains stored view indexes, which are (re)computed on each node when they are called, and so also never sent over the wire.
So, while periodic compaction is a very good idea to save disk space, it will not have an effect on repliction.