Re: Report bytes and transactions actually sent downtream

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ashu(dot)coek88(at)gmail(dot)com
Cc: michael(at)paquier(dot)xyz, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, bertranddrouvot(dot)pg(at)gmail(dot)com, andres(at)anarazel(dot)de, shveta(dot)malik(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Report bytes and transactions actually sent downtream
Date: 2026-06-12 06:59:30
Message-ID: 20260612.155930.1093703227762926511.horikyota.ntt@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Let me go back to the original motivation.

As I understand it, the problem was that, among several subscribers
connected through different slots, one slot was lagging behind. The
total_txns and total_bytes values for that slot appeared smaller, and
you wanted to know where the bottleneck was.

I wonder if part of the confusion comes from the fact that it is not
yet clear what conclusions a user is expected to draw from these new
values.

What I am still not quite sure about is how the proposed sent_bytes
value would be used to make that distinction. It sounds like the idea
is not necessarily to look at its rate over time, but perhaps to
compare total_bytes with the proposed sent_bytes. However, as has
been discussed, these two values seem to measure different things, so
I am not sure that such a comparison would be straightforward.

I think it would help move the discussion forward if you could explain
more concretely how these new values would be used to identify the
bottleneck in the case you described.

Personally, in such a situation, I would first add some temporary
instrumentation at a few likely points and print the values with
elog() or similar, just to see which value actually distinguishes the
bottleneck. Once we know that, it should be easier to decide whether
that measurement is generally useful enough to expose in a statistics
view, and where it should be measured.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-06-12 07:02:50 Re: injection_points: Switch wait/wakeup to use atomics rather than latches
Previous Message Chao Li 2026-06-12 06:56:39 Re: pg_restore handles extended statistics inconsistently with statistics data