From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Report reorder buffer size |
Date: | 2025-08-26 09:53:59 |
Message-ID: | CAExHW5tfN+RHZBXaAzfUVOfdZuqHr1Jmud8yEzu8Bkv7s2DqMA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> >
> > > If we are going
> > > to report so much statistics about the contents of the reorder buffer,
> > > is it better to have a separate view pg_stat_reorder_buffer for the
> > > same?
> >
> > Given logical decoding can be used also by regular backend processes,
> > I guess that such dynamic metrics would fit a system view dedicated to
> > logical decoding, say pg_stat_reorder_buffer or
> > pg_stat_logical_decoding.
>
> Hmm. That means we will have to reserve some area in the shared memory
> with as many slots as the number of replication slots (since that is
> the maximum number of reorder buffers that can be in the system) and
> use each one to maintain the stats. I haven't yet checked whether we
> could use the stats maintaining system for it, but it should be
> doable.
I think the beauty of reporting the statistics only for WAL senders,
as is done with the patch, was that we could piggyback stats update on
current logic to update WalSnd. If we want to do it for other
backends, it would be an extra overhead to lock and update the stats
outside WalSnd. And as I said in my email, WAL senders would be
arguably only serious users of logical decoding whose usage will be
worth monitoring - that's why pg_stat_replication reports only stats
about WAL senders and not other backends. Even if we report stats
about only WAL senders, it should be possible to report them through a
view other than pg_stat_replication. What's your opinion about this?
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2025-08-26 09:58:28 | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
Previous Message | Richard Guo | 2025-08-26 09:50:26 | Re: [BUG] Remove self joins causes 'variable not found in subplan target lists' error |