Re: pg_stat_wal: tracking the compression effect

On 2022-08-27 16:48, Bharath Rupireddy wrote:
> On Fri, Aug 26, 2022 at 8:39 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>>
>> At Fri, 26 Aug 2022 11:55:27 +0900 (JST), Kyotaro Horiguchi
>> <horikyota(dot)ntt(at)gmail(dot)com> wrote in
>> > At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato <katouknl(at)oss(dot)nttdata(dot)com> wrote in
>> > > Accumulating the values, which indicates how much space is saved by
>> > > each compression (size before compression - size after compression),
>> > > and keep track of how many times compression has happened. So that one
>> > > can know how much space is saved on average.
>> >
>> > Honestly, I don't think its useful much.
>> > How about adding them to pg_waldump and pg_walinspect instead?
>> >
>> > # It further widens the output of pg_waldump, though..
>>
>> Sorry, that was apparently too short.
>>
>> I know you already see that in per-record output of pg_waldump, but
>> maybe we need the summary of saved bytes in "pg_waldump -b -z" output
>> and the corresponding output of pg_walinspect.
>
> +1 for adding compression stats such as type and saved bytes to
> pg_waldump and pg_walinspect given that the WAL records already have
> the saved bytes info. Collecting them in the server via pg_stat_wal
> will require some extra effort, for instance, every WAL record insert
> requires that code to be executed. When users want to analyze the
> compression efforts they can either use pg_walinspect or pg_waldump
> and change the compression type if required.

Thank you for all the comments!

I will go with adding the compression stats in pg_waldump and
pg_walinspect.

Regards,
--
Ken Kato
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION