MIME-Version: 1.0
References: <Zta482TuN7ri1Bis@ip-10-97-1-34.eu-west-3.compute.internal>
 <202409051303.qumelxccgzzn@alvherre.pgsql> <Ztm811fM73GFt4z/@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZtsZtaRza9bFFeF8@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN55FZ0mnVe4rra2WXca=j+7fabVRY8uhRFPXFmkdRW9J4dKbQ@mail.gmail.com>
 <ZuRjxA+ysI4mpTSq@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN55FZ0_0Fj6No-axtDF-jrPQKh6a-qLoU73mpSAG417D+A-NA@mail.gmail.com> <Zul++79EOPsFB+Gd@ip-10-97-1-34.eu-west-3.compute.internal>
In-Reply-To: <Zul++79EOPsFB+Gd@ip-10-97-1-34.eu-west-3.compute.internal>
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: Tue, 17 Sep 2024 16:47:51 +0300
Message-ID: <CAN55FZ0xEC6K=EqTwboHJtzZnENDoEwvWOerKkHbZwFT-cU6XQ@mail.gmail.com>
Subject: Re: per backend I/O statistics
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAN55FZ0xEC6K%3DEqTwboHJtzZnENDoEwvWOerKkHbZwFT-cU6XQ%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, 17 Sept 2024 at 16:07, Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> On Tue, Sep 17, 2024 at 02:52:01PM +0300, Nazir Bilal Yavuz wrote:
> > Could we remove pg_stat_get_my_io() completely and use
> > pg_stat_get_backend_io() with the current backend's pid to get the
> > current backend's stats?
>
> The reason why I keep pg_stat_get_my_io() is because (as mentioned in [1]), the
> statistics snapshot is build for "my backend stats" (means it depends of the
> stats_fetch_consistency value). I can see use cases for that.
>
> OTOH, pg_stat_get_backend_io() behaves as if stats_fetch_consistency is set to
> none (each execution re-fetches counters from shared memory) (see [2]). Indeed,
> the snapshot is not build in each backend to copy all the others backends stats,
> as 1/ I think that there is no use case (there is no need to get others backends
> I/O statistics while taking care of the stats_fetch_consistency) and 2/ that
> could be memory expensive depending of the number of max connections.
>
> So I think it's better to keep both functions as they behave differently.
>
> Thoughts?

Yes, that is correct. Sorry, you already had explained it and I had
agreed with it but I forgot.

> > If you meant the same thing, please don't
> > mind it.
>
> What I meant to say is to try to remove the duplicate code that we can find in
> those 3 functions (say creating a new function that would contain the duplicate
> code and make use of this new function in the 3 others). Did not look at it in
> details yet.

I got it, thanks for the explanation.

--
Regards,
Nazir Bilal Yavuz
Microsoft