From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, magnus(at)hagander(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead |
Date: | 2021-08-31 02:55:35 |
Message-ID: | cb05d86190cfe11bb0ff56aefa34734ca55384ab.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2021-08-27 at 13:57 +0900, Michael Paquier wrote:
> > I think in that case we'd have to do the bigger redesign and move "live"
> > connection stats to backend_status.c...
>
> Hmm. A redesign is not really an option for 14 at this stage. And I
> am not really comfortable with the latest proposal from upthread to
> plug in that to pgstat_send_tabstat to report things once per
> transaction, either. It really looks like this needs more thoughts,
> and it would mean that a revert may be the most appropriate choice
> for the moment. That's the last-resort option, surely, but we are
> post-beta3 so there is no much margin left.
In the view of that, how about doubling PGSTAT_STAT_INTERVAL to 1000
milliseconds? That would mean slightly less up-to-date statistics, but
I doubt that that will be a problem. And it should even out the increase
in statistics messages, except in the case of lots of short-lived
sessions. But in that scenario you cannot have session statistics
without lots of extra messages, and such a workload has enough performance
problems as it is, so I don't think we have to specifically worry about it.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-08-31 03:01:05 | Re: Added missing invalidations for all tables publication |
Previous Message | Andres Freund | 2021-08-31 02:38:39 | Re: archive status ".ready" files may be created too early |