Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.211.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=SS4dM1LdFseWEu+QJOljZrOmM+/9FunAyqW1wUhc0ybyPS74aWgLHZNDiQl3/6SjZ5
         dPNdzOSH2dhvS3JpDGAqE/toWrIJuuHlhE6EhQu2qbSfrWb8Uc7YL3tl7JRZqeJAK01c
         WiBKj+r3pvq9om1WB9hyJlzysY+tFTo0VVLmc=
MIME-Version: 1.0
In-Reply-To: <cadf1c691001260655v4c0818ebi3b587eed9db33e55@mail.gmail.com>
References: <844257352.1259509400633.JavaMail.jira@brutus>
	<252493028.33431264492954629.JavaMail.jira@brutus.apache.org>
	<46aeb24f1001260234n2b04d14ev3bb22bf6f47670de@mail.gmail.com>
	<cadf1c691001260301y454da252r7eae85ae5e71dfbc@mail.gmail.com>
	<46aeb24f1001260551j16ed95d0pec87441bcc8b53a2@mail.gmail.com>
	<cadf1c691001260602w69d3cce2q2350306b5e3f9b1c@mail.gmail.com>
	<e2111bbb1001260624m5ea92bddrb5803baa6803c570@mail.gmail.com>
	<cadf1c691001260655v4c0818ebi3b587eed9db33e55@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 26 Jan 2010 10:14:13 -0500
Message-ID: <e2111bbb1001260714g797a1d2cva8720f80a4554ec9@mail.gmail.com>
Subject: Re: [jira] Commented: (COUCHDB-583) storing attachments in compressed
	form and serving them in compressed form if accepted by the client
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Huh. Maybe we turned that off? We did sit down and do some tests for
the speed/size tradeoffs of using compression.

The call was just adding the compressed option to
erlang:term_to_binary/2 before writing that to disk. I'm not seeing it
either though.

I reckon we just decided to go with no compression for speed.

Paul Davis

On Tue, Jan 26, 2010 at 9:55 AM, Filipe David Manana <fdmanana@gmail.com> wrote:
> Paul,
>
> I don't see anything on couch_file that does compression (looking at trunk).
> I grepped all the couch .erl files for "gzip" and "zlib", and the only ones
> who are using compression are from the replication feature.
> $ egrep -nr 'gzip|zlib' *.erl
> couch_rep_att.erl:66: if ContentEncoding =:= "gzip" ->
> couch_rep_att.erl:67: zlib:gunzip(Data);
> couch_rep_changes_feed.erl:64: headers = Source#http_db.headers --
> [{"Accept-Encoding", "gzip"}]
> couch_rep_httpc.erl:202: "gzip" ->
> couch_rep_httpc.erl:203: zlib:gunzip(Body);
>
> Doing a quick eye scan on couch_file, I don't find anything also.
> Am I missing something?
> On Tue, Jan 26, 2010 at 3:24 PM, Paul Davis <paul.joseph.davis@gmail.com>
> wrote:
>>
>> > I do have the same opinion as you, the code would affect many of the
>> > parts
>> > regarding the compression (specially couch_stream). For doc compression,
>> > I
>> > imagine it would touch more places, and also present some difficulties
>> > to
>> > assure compatibility with the previous DB file formats.
>>
>> Just a note that docs are already stored compressed on disk.
>> Everything written through couch_file.erl gets a gzip compression
>> level 6 applied if memory serves. Which suddenly makes me wonder if an
>> optimization for attachment compression might benefit from turning
>> that off during stream writes since the stream is already compressed.
>>
>> Just a couple random thoughts.
>>
>> Paul
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com
> PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
>