Re: Different compression methods for FPI
От | Justin Pryzby |
---|---|
Тема | Re: Different compression methods for FPI |
Дата | |
Msg-id | 20220905130235.GJ31833@telsasoft.com обсуждение исходный текст |
Ответ на | Re: Different compression methods for FPI (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | pgsql-hackers |
On Mon, Sep 05, 2022 at 02:45:57PM +0200, Matthias van de Meent wrote: > Hi, > > I have a small question for those involved: I suggest to "reply all" > Context: I'm trying to get the smallest BKPIMAGE size possible > regardless of CPU cost, which means I'm trying multiple compressions > to get the smallest data possible with the options available. This > means ignoring the wal_compression GUC in XLogCompressBackupBlock and > brute-forcing the smallest compression available, potentially layering > compression methods, and returning the bimg_info compression flags > that will be stored in XLogCompressBackupBlock and used to decompress > the block's data. I think once you apply one compression method/algorithm, you shouldn't expect other "layered" methods to be able to compress it at all. I think you'll get better compression by using a higher compression level in zstd (or zlib) than with any combination of methods. A patch for configurable compression level was here: https://postgr.es/m/20220222231948.GJ9008@telsasoft.com > Is there a prescribed order of compression algorithms to apply when > (de)compressing full page images in WAL, when the bimg_info has more > than one BKPIMAGE_COMPRESS_*-flags set? That is, when I want to check > the compression of the block image with both ZSTD and LZ4, which order > is the ordering indicated by bimg_info = (COMPRESS_LZ4 | > COMPRESS_ZSTD)? There's currently a separate bit for each method, but it's not supported to "stack" them (See also the "Save bits" patch, above). This came up before when Greg asked about it. https://www.postgresql.org/message-id/20210622031358.GF29179@telsasoft.com https://www.postgresql.org/message-id/20220131222800.GY23027@telsasoft.com -- Justin
В списке pgsql-hackers по дате отправления: