| 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
| 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 |