Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Date
Msg-id 200007102132.RAA03602@candle.pha.pa.us
Whole thread Raw
In response to Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (JanWieck@t-online.de (Jan Wieck))
List 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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: AW: Re: postgres TODO
Next
From: Bruce Momjian
Date:
Subject: Re: Re: [GENERAL] PostgreSQL vs. MySQL