Re: Add pg_stat_kind_info system view

> On Thu, Jul 30, 2026 at 08:18:21AM +0900, Michael Paquier wrote:
> > In terms of this thread, more thought is a synonym of making sure that
> > your proposal [2] is good enough for the purpose to be able to monitor
> > the pgstats activity. I'll try to look double-check this part
> > separately; this naturally adds more value to the other proposal.
>
> Just adding a note about that, while I don't forget about it
> (apologies for the short digression..).
>
> pgstat_dsa_init_size() currently documents the following thing:
> /*
> * The size of the shared memory allocation for stats stored in the shared
> * stats hash table. This allocation will be done as part of the main shared
> * memory, rather than dynamic shared memory, allowing it to be initialized in
> * postmaster.
> */
>
> Switching pgstats to use the DSM registry would imply a
> dsa_create_ext(), that cannot happen in the postmaster (assert in
> dsm.c), hence a DSM registry call in pgstat_initialize(). I think
> that this initial idea may lack robustness, because we would delay the
> pgstats initialization to happen later, at the first BaseInit() rather
> than have the postmaster do the basics. I haven't looked at how this
> idea would bundle with the single user mode, but I'd feel that pgstats
> may break also in this case.

I played around with this a bit today and there are no issues with
single-user mode. dsm_create() is allowed in single-user mode

```
dsm_segment *
dsm_create(Size size, int flags)
....
.....
/*
* Unsafe in postmaster. It might seem pointless to allow use of dsm in
* single user mode, but otherwise some subsystems will need dedicated
* single user mode code paths.
*/
Assert(IsUnderPostmaster || !IsPostmasterEnvironment);
```

I have a POC with CI all passing [1] including a new test to query stats
inside single-user mode.

Where this may become questionable is because there is slightly more
locking overhead if we go with the registry approach. The registry path goes
through more locking during backend startup (attaching to the
registry's own DSA,
looking up the entry, then attaching to the pgstat DSA) compared to the
current code which does a single dsa_attach_in_place at a known address.
With a high connection churn benchmark, using -C

```
pgbench -C -c $clients -T 10 -n -f bench.sql
```

where bench.sql contains only ";", we can see some additional time,
but it's very tiny

clients | old (ms) | new (ms) | delta (ms)
--------+-----------+-----------+-----------
1 | 1.623 | 1.649 | +0.026
2 | 1.627 | 1.663 | +0.036
4 | 1.580 | 1.615 | +0.035
8 | 1.576 | 1.616 | +0.040
16 | 1.642 | 1.661 | +0.019
32 | 1.751 | 1.786 | +0.035
64 | 1.820 | 1.859 | +0.039
128 | 1.878 | 1.921 | +0.043
256 | 1.945 | 1.993 | +0.048
512 | 2.002 | 2.043 | +0.041

35-40 microseconds, but this is an extreme case of high connection churn.

This is likely what is meant by a "small efficiency win" here.

```
static Size
pgstat_dsa_init_size(void)
/*
* Create a small dsa allocation in plain shared memory. This is required
* because postmaster cannot use dsm segments. It also provides a small
* efficiency win.
*/
ctl->raw_dsa_area = p;
```

While I am not too troubled by these numbers, I am not fully on board
with taking
this approach, either. Alternatively, we can of course expose this information
using a pgstat_ specific registry as an alternative and keep things the
way they are.

[1] https://github.com/samimseih/postgres/actions/runs/30833585252

--
Sami