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