Hi, On Tue, Oct 08, 2024 at 01:46:23PM +0900, Michael Paquier wrote: > On Mon, Oct 07, 2024 at 09:54:21AM +0000, Bertrand Drouvot wrote: > > On Fri, Sep 20, 2024 at 01:26:49PM +0900, Michael Paquier wrote: > >> This would rely on the fact that we would use the ProcNumber for the > >> dshash key, and this information is not provided in pg_stat_activity. > >> Perhaps we should add this information in pg_stat_activity so as it > >> would be easily possible to do joins with a SQL function that returns > >> a SRF with all the stats associated with a given connection slot > >> (auxiliary or backend process)? > > > > I'm not sure that's needed. What has been done in the previous versions is > > to get the stats based on the pid (see pg_stat_get_backend_io()) where the > > procnumber is retrieved with something like > > GetNumberFromPGProc(BackendPidGetProc(pid)). > > Ah, I see. So you could just have the proc number in the key to > control the upper-bound on the number of possible stats entries in the > dshash.
Yes. > Assuming that none of this data is persisted to the stats file at > shutdown and that the stats of a single entry are reset each time a > new backend reuses a previous proc slot, that would be OK by me, I > guess. > > >> The active PIDs of the live sessions are not stored in the active > >> stats, why not? > > > > That was not needed. We can still retrieve the stats based on the pid thanks > > to something like GetNumberFromPGProc(BackendPidGetProc(pid)) without having > > to actually store the pid in the stats. I think that's fine because the pid > > only matters at "display" time (pg_stat_get_backend_io()). > > Okay, per the above and the persistency of the stats. Great, I'll work on an updated patch version then. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
