public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Bertrand Drouvot <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Subject: Re: per backend I/O statistics
Date: Sat, 18 Jan 2025 17:53:31 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAN55FZ0ZQTf-D+5Rup4H6zp+n3E2EuonYuzTiPkp=1GhesZU_A@mail.gmail.com>
<[email protected]>
<[email protected]>
<66efowskppsns35v5u2m7k4sdnl7yoz5bo64tdjwq7r5lhplrz@y7dme5xwh2r5>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Fri, Jan 17, 2025 at 10:23:48AM +0000, Bertrand Drouvot wrote:
> Please find attached a patch implementing the ideas above, meaning:
>
> - It creates a new PendingBackendStats variable
> - It uses this variable to increment and flush per backend pending IO statistics
>
> That way we get rid of the memory allocation for pending IO statistics.
>
> One remark: a special case has been added in pgstat_flush_pending_entries(). The
> reason is that while the per backend stats are "variable-numbered" stats, it could
> be that their pending stats are not part of pgStatPending. This is currently the
> case (with this patch) as the per backend pending IO stats are not tracked with
> pgstat_prep_backend_pending() and friends anymore.
+ /*
+ * There is a special case for some pending stats that are tracked in
+ * PendingBackendStats. It's possible that those have not been flushed
+ * above, hence the extra check here.
+ */
+ if (!pg_memory_is_all_zeros(&PendingBackendStats,
+ sizeof(struct PgStat_BackendPending)))
+ {
+ PgStat_EntryRef *entry_ref;
+
+ entry_ref = pgstat_get_entry_ref(PGSTAT_KIND_BACKEND, InvalidOid,
+ MyProcNumber, false, NULL);
Hmm. Such special complexities in pgstat.c are annoying. There is
a stupid thing I am wondering here. For the WAL stats, why couldn't
we place some calls of pgstat_prep_backend_pending() in strategic
places like XLogBeginInsert() to force all the allocation steps of the
pending entry to happen before we would enter the critical sections
when doing a WAL insertion? As far as I can see, there is a special
case with 2PC where XLogBeginInsert() could be called in a critical
section, but that seems to be the only one at quick glance.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (39+ 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], [email protected], [email protected], [email protected]
Subject: Re: per backend I/O 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