From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, laurenz(dot)albe(at)cybertec(dot)at, 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-27 04:57:45 |
Message-ID: | YShwyekYmURhtZbk@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 25, 2021 at 01:20:03AM -0700, Andres Freund wrote:
> On 2021-08-25 12:51:58 +0900, Michael Paquier wrote:
> As I said before, this ship has long sailed:
>
> typedef struct PgStat_MsgTabstat
> {
> PgStat_MsgHdr m_hdr;
> Oid m_databaseid;
> int m_nentries;
> int m_xact_commit;
> int m_xact_rollback;
> PgStat_Counter m_block_read_time; /* times in microseconds */
> PgStat_Counter m_block_write_time;
> PgStat_TableEntry m_entry[PGSTAT_NUM_TABENTRIES];
> } PgStat_MsgTabstat;
Well, I kind of misread what you meant upthread then.
PgStat_MsgTabstat has a name a bit misleading, especially if you
assign connection stats to it.
>> As of the two problems discussed on this thread, aka the increased
>> number of UDP packages and the extra timestamp computations, it seems
>> to me that we had better combine the following ideas for HEAD and 14,
>> for now:
>> - Avoid the extra timestamp computation as proposed by Laurenz in [1]
>> - Throttle the frequency where the connection stat packages are sent,
>> as of [2].
>
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-08-27 05:00:22 | Re: Error code for checksum failure in origin.c |
Previous Message | Greg Nancarrow | 2021-08-27 04:55:34 | Fix erroneous parallel execution when modifying CTE is present in rewritten query |