From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Luke Lonergan <llonergan(at)greenplum(dot)com> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TOAST compression |
Date: | 2006-02-26 19:18:31 |
Message-ID: | 20060226191831.GA5497@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Luke Lonergan wrote:
> Jim,
>
> On 2/26/06 10:37 AM, "Jim C. Nasby" <jnasby(at)pervasive(dot)com> wrote:
>
> > So the cutover point (on your system with very fast IO) is 4:1
> > compression (is that 20 or 25%?).
>
> Actually the size of the gzipp'ed binary file on disk was 65MB, compared to
> 177.5MB uncompressed, so the compression ratio is 37% (?), or 2.73:1.
I doubt our algorithm would give the same compression (though I haven't
really measured it). The LZ implementation we use is supposed to have
lightning speed at the cost of a not-so-good compression ratio.
> No, unfortunately not. O'Reilly's jobs data have 65K rows, so that would
> work. How do we implement LZW compression on toasted fields? I've never
> done it!
See src/backend/utils/adt/pg_lzcompress.c
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tino Wildenhain | 2006-02-26 19:20:28 | Re: Pl/Python -- current maintainer? |
Previous Message | Luke Lonergan | 2006-02-26 19:05:50 | Re: TOAST compression |