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

From Kyotaro Horiguchi
Subject Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date
Msg-id 20230210.113242.699878230551547182.horikyota.ntt@gmail.com
Whole thread Raw
In response to 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
List pgsql-hackers
At Thu, 9 Feb 2023 11:38:18 +0100, "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> wrote in 
> Hi hackers,
> 
> Please find attached a patch proposal for $SUBJECT.
> 
> The idea has been raised in [1] by Andres: it would allow to simplify
> even more the work done to
> generate pg_stat_get_xact*() functions with Macros.
> 
> Indeed, with the reconciliation done in find_tabstat_entry() then all
> the pg_stat_get_xact*() functions
> (making use of find_tabstat_entry()) now "look the same" (should they
> take into account live subtransactions or not).
> 
> Looking forward to your feedback,

I like that direction.

Don't we rename PgStat_FunctionCounts to PgStat_FuncStatus, unifying
neighboring functions?

Why does find_tabstat_entry() copies the whole pending data and
performs subxaction summarization? The summarization is needed only by
few callers but now that cost is imposed to the all callers along with
additional palloc()/pfree() calls. That doesn't seem reasonable.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply
Next
From: Andreas Karlsson
Date:
Subject: Re: ICU locale validation / canonicalization