Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
От | Bruce Momjian |
---|---|
Тема | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Дата | |
Msg-id | 200007102132.RAA03602@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... (JanWieck@t-online.de (Jan Wieck)) |
Список | 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 по дате отправления: