Re: RFC: Detailed reorder buffer stats dumps

From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Detailed reorder buffer stats dumps
Date: 2021-06-29 06:01:21
Message-ID: CAGRY4nz13DvpuEVAQZUk9m9-SaZ9JdD7Jz5C66j8cA5Y7ZkY8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 6 May 2021 at 19:40, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Thu, May 6, 2021 at 9:54 AM Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> >

> At the least it'd be helpful to have pg_stat_replication (or a new
> related auxiliary view like pg_stat_logical_decoding) show
> >
> > - walsender total bytes sent this session
> > - number of txns processed this txn
> >
>
> You might be able to derive some of the above sorts of stats from the
> newly added pg_stat_replication_slots [1].
>
>
That's a huge improvement that I managed to totally miss the discussion of
and work on. Thanks. It'll be a significant help.
'

> > - number txns filtered out by output plugin this session
> > - oldest xid in reorder buffer
> > - reorder buffer number of txns
> > - reorder buffer total size (in-memory and total inc spilled)
> > - reorderbuffercommit current xid, last change lsn, total buffered size
> of current tx, total bytes of buffer processed so far within the current
> txn, and commit lsn if known, only when currently streaming a txn from
> reorderbuffercommit
>

These are less statistical in nature, and more about the current activity
of the walsender and logical decoding state. I'm not sure if it'd make much
sense to tack them on to pg_stat_replication_slots, especially as that'd
also mean they were quite delayed.

But it probably isn't worth the effort of exposing this info in a new view.

With the higher level info now available in pg_stat_replication_slots, I
think I might look into exposing these finer details via trace markers for
use with perf / systemtap / etc instead.

A digression, but: It's a real shame that such tools don't give us a way to
read specific tagged regions of memory with the same ease they let us probe
function calls though. You generally need gdb to read the value of a
global, or a moderately funky systemtap script. There's no convenient
equivalent to SDT markers (TRACE_FOO) to tag variables. Wouldn't it be nice
if we could

perf watch postgres:walsender_reorderbuffer_oldest_xid

or something like that?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-06-29 06:17:11 Re: Add index OID macro argument to DECLARE_INDEX
Previous Message Tom Lane 2021-06-29 05:53:42 Re: Dump public schema ownership & seclabels