Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

Hi,

On 2/10/23 3:32 AM, Kyotaro Horiguchi wrote:
> 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.
> 

Thanks for looking at it!

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

Not sure, I think it's the counter part of PgStat_TableCounts for example.

> Why does find_tabstat_entry() copies the whole pending data and
> performs subxaction summarization? 

It copies the pending data to not increment it's counters while doing the summarization.
The summarization was done here to avoid the pg_stat_get_xact*() functions to do the computation so that all
the pg_stat_get_xact*() functions look the same but....

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

I agree that's not the best approach.....

Let me come back with another proposal (thinking to increment reconciled
counters in pgstat_count_heap_insert(), pgstat_count_heap_delete() and
pgstat_count_heap_update()).

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com