Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead
Date
Msg-id YShwyekYmURhtZbk@paquier.xyz
Whole thread Raw
In response to Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead  (Andres Freund <andres@anarazel.de>)
Responses Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead  (Andres Freund <andres@anarazel.de>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Fix erroneous parallel execution when modifying CTE is present in rewritten query
Next
From: Michael Paquier
Date:
Subject: Re: Error code for checksum failure in origin.c