Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL HACKERS <pgsql-hackers@postgresql.org>
Date: 2000-07-10T21:32:35Z
Lists: pgsql-hackers
>     Compressor | level | heap size | toastrel | toastidx | seconds
>                |       |           |   size   |   size   |
>     -----------+-------+-----------+----------+----------+--------
>     PGLZ       |   -   |   425,984 |  950,272 |   32,768 |    5.20
>     zlib       |   1   |   499,712 |  614,400 |   16,384 |    6.85
>     zlib       |   3   |   499,712 |  557,056 |   16,384 |    6.75
>     zlib       |   6   |   491,520 |  524,288 |   16,384 |    7.10
>     zlib       |   9   |   491,520 |  524,288 |   16,384 |    7.21

Consider that the 25% slowness gets us a 35% disk reduction, and that
translates to fewer buffer blocks and disk accesses.  Seems there is a
clear tradeoff there.

>     If replacing the compressor/decompressor can cause a  runtime
>     difference  of  25%  in  such a scenario, the pure difference
>     between the two methods must be alot.
> 
>     Leave  PGLZ  in place as the default compressor for toastable
>     types.  Speed is what all benchmarks talk  about  -  on  disk
>     storage size is seldom a minor note.

True, disk storage is not the issue, but disk access are an issue.

>     We  can  discuss  about  enabling  zlib  as  a  per attribute
>     configurable alternative further. But is the  confusion  this
>     might cause worth it all?

I think we have to choose one proposal.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026