wal stats questions - Mailing list pgsql-hackers

From Andres Freund
Subject wal stats questions
Date
Msg-id 20210324232224.vrfiij2rxxwqqjjb@alap3.anarazel.de
Whole thread Raw
Responses Re: wal stats questions  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
List pgsql-hackers
Hi,

I got a few questions about the wal stats while working on the shmem
stats patch:

1) What is the motivation to have both prevWalUsage and pgWalUsage,
   instead of just accumulating the stats since the last submission?
   There doesn't seem to be any comment explaining it? Computing
   differences to previous values, and copying to prev*, isn't free. I
   assume this is out of a fear that the stats could get reset before
   they're used for instrument.c purposes - but who knows?

2) Why is there both pgstat_send_wal() and pgstat_report_wal()? With the
   former being used by wal writer, the latter by most other processes?
   There again don't seem to be comments explaining this.

3) Doing if (memcmp(&WalStats, &all_zeroes, sizeof(PgStat_MsgWal)) == 0)
   just to figure out if there's been any changes isn't all that
   cheap. This is regularly exercised in read-only workloads too. Seems
   adding a boolean WalStats.have_pending = true or such would be
   better.

4) For plain backends pgstat_report_wal() is called by
   pgstat_report_stat() - but it is not checked as part of the "Don't
   expend a clock check if nothing to do" check at the top.  It's
   probably rare to have pending wal stats without also passing one of
   the other conditions, but ...

Generally the various patches seems to to have a lot of the boilerplate
style comments (like "Prepare and send the message"), but very little in
the way of explaining the design.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Refactor SSL test framework to support multiple TLS libraries
Next
From: Alvaro Herrera
Date:
Subject: Re: Refactor SSL test framework to support multiple TLS libraries