On Sun, Jun 15, 2025 at 6:21 AM Andrew Johnson <andrewj@metronome.com> wrote:
>
> To address your other concerns:
>
> > Since these counters are global, not aggregatable per backend
>
> I understand this perspective, though I'd suggest that PostgreSQL
> already uses the pgstats pattern for similar global metrics, such as:
>
> - pg_stat_wal
> - pg_stat_bgwriter
> - pg_stat_checkpointer
> - pg_stat_archiver
>
> These all share similar characteristics with multixact member counts:
> global scope and used for cluster-wide resource monitoring.
All these are cumulative stats, which need period collection and
accumulation of statistics which doesn't naturally happen in their
respective subsystems. multixact members are already in an
"accumulated" state in MultiXactState. I don't think we need a
separate mechanism just to copy those accumulated stats as your patch
proposes. It's an additional overhead which is not required. However,
there's some advantage of avoiding acquiring MultiXactGenLock for
reporting the multixact stats. However your approach too requires a
lock for updating and reading stats. The stats are updated
periodically, irrespective of whether someone is reading it or not. So
there's some wastage of CPU cycles if the stats is read less
frequently than it's updated. Naga's approach doesn't have this
drawback and also he has shown that the overhead of acquiring
MultiXactGenLock isn't noticeable. In that sense his implementation
looks closer to what we do in pg_stat_get_wal_senders() - which also
feeds another stats view pg_stat_replication.
I am leaning towards Naga's approach, which is simpler. But there
might be others who feel otherwise.
One drawback of Naga's approach is that it doesn't report the space
consumed on the disk, which is more important than the member count.
If you approach allows to do that easily, that will be an added
advantage.
--
Best Wishes,
Ashutosh Bapat
