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
