Date: Mon, 4 Nov 2024 10:01:50 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: per backend I/O statistics
Message-ID: <ZyibjiLgoLx+kS4n@ip-10-97-1-34.eu-west-3.compute.internal>
References: <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>
 <CAN55FZ0xEC6K=EqTwboHJtzZnENDoEwvWOerKkHbZwFT-cU6XQ@mail.gmail.com>
 <ZumKktat4RtHmxL/@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zuz5iQ4AjcuOMx_w@paquier.xyz>
 <ZwOvzX219kDhEEMu@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZwS5H5Fu0LnSev90@paquier.xyz>
 <ZwVdt8/0tTu5pv8K@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZyMRJIbUpNPoCXUe@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZyMRJIbUpNPoCXUe@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/ZyibjiLgoLx%2BkS4n%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Thu, Oct 31, 2024 at 05:09:56AM +0000, Bertrand Drouvot wrote:
> === OPTIONS ===
> 
> So, based on this, I think that we could:
> 
> Option 1: "move" the existing PGSTAT_KIND_IO to variable-numbered and let this
> KIND take care of the aggregated view (pg_stat_io) and the per-backend stats.
> 
> Option 2: let PGSTAT_KIND_IO as it is and introduce a new PGSTAT_KIND_BACKEND_IO
> that would be variable-numbered.
> 
> Option 3: Remove PGSTAT_KIND_IO, introduce a new PGSTAT_KIND_BACKEND_IO that
> would be variable-numbered and store the "aggregated stats aka pg_stat_io" in
> shared memory (not part of the variable-numbered hash). Per-backend stats
> could be aggregated into "pg_stat_io" during the flush_pending_cb call for example.
> 
> === BEST OPTION? ===
> 
> I would opt for Option 2 as:
> 
> - The stats system is currently not designed for Option 1 and our goals (for
> example the shared_data_len is used to serialize but also to fetch the entries,
> see pgstat_fetch_entry()) so that would need some hack to serialize only a part
> of them and still be able to fetch them all).
> 
> - Mixing "fixed" and "variable" in the same KIND does not sound like a good idea
> (though that might be possible with some hacks, I don't think that would be 
> easy to maintain).
> 
> - Having the per-backend as "variable" in its dedicated kind looks more reasonable
> and less error-prone.
> 
> - I don't think there is a stats design similar to option 3 currently, so I'm
> not sure there is a need to develop something new while Option 2 could be done.
> 
> - Option 3 would need some hack for (at least) the "pg_stat_io" [de]serialization
> part.
> 
> - Option 2 seems to offer more flexibility (as compare to Option 1 and 3).
> 
> Thoughts?

And why not add more per-backend stats in the future? (once the I/O part is done).

I think that's one more reason to go with option 2 (and implementing a brand new
PGSTAT_KIND_BACKEND kind).

Thoughts?

Regards,

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