Re: Per backend relation statistics tracking

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

In response to

Responses

Browse pgsql-hackers by date

  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