public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bertrand Drouvot <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected]
Subject: Re: per backend WAL statistics
Date: Thu, 23 Jan 2025 09:57:50 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<xibh465r3x7xvpzaozu47fxule3dktvwz4yacce4pjlw76lkjd@fjvm56zbev37>
	<Z4k9rb3aTNVSmyq/@ip-10-97-1-34.eu-west-3.compute.internal>
	<aj5vdgpbux5e2dbr6gcgd4eu3krjrflljt2neivh2vbkfrlant@2qedfymz7lmh>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

On Thu, Jan 23, 2025 at 05:05:30PM +0900, Michael Paquier wrote:
> On Tue, Jan 21, 2025 at 07:19:55AM +0000, Bertrand Drouvot wrote:
> > PFA v6 that now relies on the new PendingBackendStats variable introduced in
> > 4feba03d8b9.
> > 
> > Remark: I moved PendingBackendStats back to pgstat.h because I think that the
> > "simple" pending stats increment that we are adding in xlog.c are not worth
> > an extra function call overhead (while it made more sense for the more complex IO
> > stats handling). So PendingBackendStats is now visible to the outside world like
> > PendingWalStats and friends.
> 
> You are re-doing here a pattern I was trying to avoid so as we don't
> copy-paste more checks based on pgstat_tracks_backend_bktype more than
> necessary.

I'm not sure I get it. pgstat_tracks_backend_bktype() is also called in
pgstat_count_backend_io_op() and pgstat_count_backend_io_op_time(). What issue
do you see with the extra calls part of this patch?

> I am wondering if we should think harder about the
> interface used to register WAL stats, and make it more consistent with
> the way pg_stat_io is handled, avoiding the hardcoded attribute
> numbers if we have an enum to control which field to update in some
> input routine.

Not sure as WAL stats just tracks a single dimension unlike IO stats which track
both IOObject and IOContext. What would be the benefit(s)?

> As we have only five counters in PgStat_PendingWalStats, the result
> you have is not that invasive, true.

And only one dimension.

> Are you sure that the interactions between pgWalUsage, prevWalUsage
> and prevBackendWalUsage are correct?

I think so and according to my testing I can see WalUsage values
that correlate nicely between pg_stat_wal() and pg_stat_get_backend_wal().

> As far I got it from a code
> read, prevWalUsage, prevBackendWalUsage and their local trackings in
> pgstat_backend.c and pgstat_wal.c rely on instrument.c as the primary
> source, as pgWalUsage can never be reset.  Is that right?

yeah, IIUC pgWalUsage acts as the primary source that both prevWalUsage and
prevBackendWalUsage diff against to calculate incremental stats.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: per backend WAL statistics
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox