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

Hi,

On 3/27/23 8:35 AM, Michael Paquier wrote:
> On Fri, Mar 24, 2023 at 08:00:44PM -0700, Andres Freund wrote:
>> I don't understand what we're optimizing for here. These functions are very
>> very very far from being a hot path. The xact functions are barely ever
>> used. Compared to the cost of query evaluation the cost of iterating throught
>> he subxacts is neglegible.
> 
> I was wondering about that, and I see why I'm wrong.  I have quickly
> gone up to 10k subtransactions, and while I was seeing what looks like
> difference of 8~10% in runtime when looking at
> pg_stat_xact_all_tables, the overval runtime was still close enough
> (5.8ms vs 6.4ms).  At this scale, possible that it was some noise,
> these seemed repeatable still not to worry about.
> 
> Anyway, I was looking at this patch, and I still feel that it is a bit
> incorrect to have the copy of PgStat_TableStatus returned by
> find_tabstat_entry() to point to the same list of subtransaction data
> as the pending entry found, while the counters are incremented.  This
> could lead to mistakes if the copy from find_tabstat_entry() is used
> in an unexpected way in the future.  The current callers are OK, but
> this does not give me a warm feeling :/

FWIW, please find attached V7 (mandatory rebase).

It would allow to also define:

- pg_stat_get_xact_tuples_inserted
- pg_stat_get_xact_tuples_updated
- pg_stat_get_xact_tuples_deleted

as macros, joining others pg_stat_get_xact_*() that are already
defined as macros.

The concern you raised above has not been addressed, meaning that
find_tabstat_entry() still return a copy of PgStat_TableStatus.

By "used in an unexpected way in the future", what do you mean exactly? Do you mean
the caller forgetting it is working on a copy and then could work with
"stale" counters?

Trying to understand to see if I should invest time to try to address your concern
or leave those 3 functions as they are currently before moving back to the
"Split index and table statistics into different types of stats" work [1].


[1]: https://www.postgresql.org/message-id/flat/f572abe7-a1bb-e13b-48c7-2ca150546822@gmail.com

Regards,

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