From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Per backend relation statistics tracking |
Date: | 2025-08-26 00:22:43 |
Message-ID: | CAA5RZ0tX1wLkMxN1d=iYk9AvQ63Jup1haKeBMBeZsCu8xApzdw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Adding these fields to the backend level stats spread based on the
> backend PID without the knowledge of the relation they're related with
> makes it much less interesting IMO, because we lose a lot of
> granularity value that we have with the pg_statio_* relations, at the
> cost of more bloat, particularly if these numbers are distributed
> across many relations.
I think the flip side of the argument is that the current per-table metrics
don't tell us which of our backends ( by user, application_name )
are contributing to a specific type of activity.
Would it be interesting to try to answer a question such as
"Does application_name = AppA perform more sequential scans than AppB?"
or "does UserA perform more index scans than UserB?" Currently, we don't
have an easy way to figure out such information, without some sort of a
DML trigger.
--
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-08-26 00:28:04 | Re: Per backend relation statistics tracking |
Previous Message | Nathan Bossart | 2025-08-26 00:14:40 | Re: Improve LWLock tranche name visibility across backends |