public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Bertrand Drouvot <[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: Wed, 6 Nov 2024 08:39:07 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <ZypXy3fH/[email protected]>
References: <[email protected]>
<CAN55FZ0xEC6K=EqTwboHJtzZnENDoEwvWOerKkHbZwFT-cU6XQ@mail.gmail.com>
<ZumKktat4RtHmxL/@ip-10-97-1-34.eu-west-3.compute.internal>
<[email protected]>
<[email protected]>
<[email protected]>
<ZwVdt8/[email protected]>
<[email protected]>
<[email protected]>
<ZypXy3fH/[email protected]>
On Tue, Nov 05, 2024 at 05:37:15PM +0000, Bertrand Drouvot wrote:
> I'm starting working on option 2, I think it will be easier to discuss with
> a patch proposal to look at.
>
> If in the meantime, one strongly disagree with option 2 (means implement a brand
> new PGSTAT_KIND_BACKEND and keep PGSTAT_KIND_IO), please let me know.
Sorry for the late reply, catching up a bit.
As you are quoting in [1], you do not expect the backend-io stats and
the more global pg_stat_io to achieve the same level of consistency as
the backend stats would be gone at restart, and wiped out when a
backend shuts down. So, splitting them with a different stats kind
feels more natural because it would be possible to control how each
stat kind behaves depending on the code shutdown and reset paths
within their own callbacks rather than making the callbacks of
PGSTAT_KIND_IO more complex than they already are. And pg_stat_io is
a fixed-numbered stats kind because of the way it aggregates its stats
with a number states defined at compile-time.
Is the structure you have in mind different than PgStat_BktypeIO?
Perhaps a split is better anyway with that in mind.
The amount of memory required to store the snapshots of backend-IO
does not worry me much, TBH, but you are worried about a high turnover
of connections that could cause a lot of bloat in the backend-IO
snapshots because of the persistency that these stats would have,
right? Actually, we already have cases with other stats kinds where
it is possible for a backend to hold references to some stats on an
object that has been dropped concurrently. At least, that's possible
when a backend shuts down. If possible, supporting snapshots would be
more consistent with the other stats.
Just to be clear, I am not in favor of making PgStat_HashKey larger
than it already is. With 8 bytes allocated for the object ID, the
chances of conflicts in the dshash for a single variable-numbered
stats kind play in our favor already even with a couple of million
entries.
[1]: https://www.postgresql.org/message-id/[email protected]
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (32+ 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]
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