Re: Compression of bigger WAL records

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: surya poondla <suryapoondla4(at)gmail(dot)com>
Cc: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Subject: Re: Compression of bigger WAL records
Date: 2026-08-19 08:11:02
Message-ID: CAO6_XqqPHc+a8izdtOZXn_24qTnFriLOO-hEYM2WCBUR+146tw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 18, 2026 at 3:48 PM Anthonin Bonnefoy
<anthonin(dot)bonnefoy(at)datadoghq(dot)com> wrote:
> I'm a bit surprised by the 1.3MB estimation, how did you find this
> amount? If I check with ZSTD_sizeof_CCtx just after the context is
> created, I have:
> (gdb) p ZSTD_sizeof_CCtx(zstd_cctx)
> $1 = 5288
>
> After being used once, it seems to stay stable with:
> (gdb) p ZSTD_sizeof_CCtx(zstd_cctx)
> $5 = 154261
> So it looks closer to 152KB.
>
> + if (zstd_cctx == NULL)
> + zstd_cctx = ZSTD_createCCtx();

On a second look, 1.3MB is the size reported by ZSTD_estimateCCtxSize
with the default compression level for the worst case. So it's the
maximum memory a cctx can use, and my test was probably not enough to
reach this.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-19 08:11:54 Re: [PATCH] Fix heap-buffer-overflow in PGTYPEStimestamp_defmt_scan()
Previous Message Daniel Gustafsson 2026-08-19 08:04:37 Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)?