Thread

Re: contrib/pg_stat_tcpinfo

Jakub Wartak <jakub.wartak@enterprisedb.com> — 2025-11-10T08:34:58Z

On Sat, Nov 8, 2025 at 1:18 AM Andres Freund <andres@anarazel.de> wrote:

Hi Andres!

>> But maybe it's very useful in practice, don't know.

> FWIW, I've needed this many times. Without the TCP information it's very hard
> to figure out why higher latency connections aren't keeping up - is it packet
> loss, it it too small network buffers on the sending/receiving side, is it the
> remote side not keeping up on the CPU level...

Pretty much the same!

> > I don't follow? Why do you want to format data the way "ss" does?
>
> Yea, I don't get that either - IMO ss's format is just about the worst
> possible format. It's very hard to parse and doesn't seem to have advantages
> making up for that.

Well yes, I've probably used the wrong expression there ("format as
the ss does"). Technically `ss` might return multiple lines and lacks
extraction of specific hosts/ports (well one can use filters, but...),
but here we have normal fields like src/dst/srcport/dstport + we can
apply WHERE on extracted JSON columns (->). I think it's way better in
pg_stat_tcpinfo even today than in ss, but I could adapt further based
on some feedback. E.g. rather than appending Vegas/BBR info like `ss`
does, we could put nested structure, just like I've did with "skmem",
so technically it's the same data as in ss, but format would not be
exactly the same, but use similar-looking names, so that someone
familiar with `ss` would know how to use it.

Still , it is still PoC, and I'm not sure if the community is open to
accept (or reject it).

-J.