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

From Andres Freund
Subject Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead
Date
Msg-id 20210825082003.eaeldmt7o7yao5y5@alap3.anarazel.de
Whole thread Raw
In response to Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On 2021-08-25 12:51:58 +0900, Michael Paquier wrote:
> I was looking at this WIP patch, and plugging in the connection
> statistics to the table-access statistics looks like the wrong
> abstraction to me.  I find much cleaner the approach of HEAD to use a
> separate API to report this information, as of
> pgstat_send_connstats().

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;


> 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...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead
Next
From: Amit Kapila
Date:
Subject: Re: row filtering for logical replication