Re: Recover space imposed by 4K minimum document size?

[Travis Downs <tr...@gmail.com>]

Well that was it. I guess the compaction via the _utils UI simply was never
working. After triggering it with curl, the DB size came down 10x and is
now equal (actually slightly less than, due to compression, I suppose) the
document size.

Thanks!

On Tue, Jun 30, 2015 at 1:35 PM, Adam Kocoloski <ko...@apache.org> wrote:

> Perhaps try triggering the compaction directly from the API with curl?
>
> http://docs.couchdb.org/en/1.6.1/api/database/compact.html
>
> Adam
>
> > On Jun 30, 2015, at 3:45 AM, Travis Downs <tr...@gmail.com>
> wrote:
> >
> > I ran compaction via the button in _utils. I did notice that when I
> > clicked the button, the spinner in the UI never stops, but I did check
> > that compact_running was "false" for the DB in question - so I assumed
> > it finished. I suppose some issue with _utils could instead mean it
> > never started? Is there some way to distinguish the two cases?
> >
> > On Mon, Jun 29, 2015 at 5:49 PM, Adam Kocoloski <ko...@apache.org>
> wrote:
> >> Database compaction should absolutely recover that space. Can you share
> a few more details? Are you sure the compaction completes successfully?
> Cheers,
> >>
> >> Adam
> >>
> >>> On Jun 29, 2015, at 8:19 PM, Travis Downs <tr...@gmail.com>
> wrote:
> >>>
> >>> I have an issue where I'm posting single smallish (~500 bytes)
> >>> documents to couchdb, yet the DB size is about 10x larger than
> >>> expected (i.e., 10x larger than the aggregate size of the documents).
> >>>
> >>> Documents are not deleted or modified after posting.
> >>>
> >>> It seems like what is happening is that every individual (unbatched
> >>> write) always takes 4K due to the nature of the append-only algorithm
> >>> writing 2 x 2K blocks for each modification as documented here:
> >>>
> >>> http://guide.couchdb.org/draft/btree.html
> >>>
> >>> OK, that's fine. What I don't understand is why the "compact"
> >>> operation doesn't recover this space?
> >>>
> >>> I do recover the space if I replicate this DB somewhere else. The full
> >>> copy takes about 10x less space. I would expect replicate to be able
> >>> to do the same thing in place. Is there some option I'm missing?
> >>>
> >>> Note that I cannot use bulk writes since the documents are posted one
> >>> by one by different clients.
> >>>
> >>
> >
>
>