Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

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

In response to

Responses

Browse pgsql-hackers by date

  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