Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date
Msg-id ZB5i1lt3v/AUSvpq@paquier.xyz
Whole thread Raw
In response to Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Mar 16, 2023 at 02:13:45PM +0100, Drouvot, Bertrand wrote:
> On 3/16/23 12:46 PM, Michael Paquier wrote:
>>> I don't think we should pay any particular attention to those 2 ones
>>> as anyway nothing prevent the 7 others to be called outside of the
>>> pg_stat_xact_all_tables view.
>>
>> I am not quite sure, TBH.  Did you look at the difference with a long
>> chain of subtrans, like savepoints?  The ODBC driver "loves" producing
>> a lot of savepoints, for example.
>
> No, I did not measure the impact.

I have been thinking again about this particular point, and I would be
fine with an additional boolean flag to compute the subtrans data in
the global counter when only necessary.  This would not make the
macros for the stat functions that much more complicated, while being
sure that we don't do unnecessary computations when we know that we
don't need them..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Progress report of CREATE INDEX for nested partitioned tables
Next
From: Andres Freund
Date:
Subject: hio.c does visibilitymap_pin()/IO while holding buffer lock