Re: per backend I/O statistics

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: per backend I/O statistics
Date: 2024-10-08 04:46:23
Message-ID: ZwS5H5Fu0LnSev90@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2024-10-08 05:00:27 Re: MergeJoin beats HashJoin in the case of multiple hash clauses
Previous Message Andrei Lepikhov 2024-10-08 04:33:36 Re: Incremental Sort Cost Estimation Instability