| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Sami Imseih <samimseih(at)gmail(dot)com> |
| Subject: | Re: Redesign per-backend statistics |
| Date: | 2026-09-22 00:16:30 |
| Message-ID: | arHI3tQDbpnd2El2@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 21, 2026 at 05:17:04AM -0400, Andres Freund wrote:
> On 2026-09-21 07:15:44 +0000, Bertrand Drouvot wrote:
>> +/* -------------------------------------------------------------------------
>> + *
>> + * pgstat_per_backend.c
>> + * Generic infrastructure for per-backend statistics.
>> + *
>> + * This file manages the dedicated per-kind dshashes used for per-backend
>> + * statistics, including entry creation, fetching, snapshots, transfer to
>> + * global statistics, and removal.
>
> It's not entirely obvious to me that a hash table is needed here. If I
> understand correctly, this just going to be used for per-backend versions of
> fixed stats. Which means we could just as well allocate all the memory in
> statically allocated shared memory at server start and have the per-backend
> stats be accessible by nothing more than an array access?
Yeah. Array access based on an procnum index is still feeling like
the natural thing to do here (I think I've mentioned that upthread?).
It's cheap to initialize, cheaper to access for reads and writes of
the data than one or two hash tables. For hot paths, that would
matter.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-09-22 00:18:25 | Re: Add a permission check to pg_stat_get_backend_subxact() |
| Previous Message | shihao zhong | 2026-09-22 00:12:39 | Re: aio: worker: Free SMGR objects when idle |