You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jan Lehnardt (JIRA)" <ji...@apache.org> on 2010/08/24 13:08:17 UTC

[jira] Closed: (COUCHDB-437) Make compression level configurable, and allow attachments to be compressed

     [ https://issues.apache.org/jira/browse/COUCHDB-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Lehnardt closed COUCHDB-437.
--------------------------------

    Resolution: Duplicate

> Make compression level configurable, and allow attachments to be compressed
> ---------------------------------------------------------------------------
>
>                 Key: COUCHDB-437
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-437
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>            Reporter: Jason Davies
>            Priority: Minor
>         Attachments: couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch, couchdb-583-trunk-6th-try.patch
>
>
> As suggested by Adam Kocolosk in http://www.mail-archive.com/dev@couchdb.apache.org/msg02858.html
> > The nice thing is that binary_to_term seems perfectly happy reading a mix of compressed and uncompressed binaries, which means the compression level can be a configuration parameter if we want it to be. gzip decompresses pretty quickly, so I'm guessing that reading a compressed DB will be faster than an uncompressed one. We'll have to measure it, though.
> Just thinking that space may be at a premium for some users and enabling compression could save them quite a bit of space depending on the data stored in docs.  Compressing attachments could be beneficial too, and for particular use cases compression might increase read throughput due to needing less disk reads.  As Adam says, we need to measure it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.