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.gj9...@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.gf29...@telsasoft.com https://www.postgresql.org/message-id/20220131222800.gy23...@telsasoft.com -- Justin
