Horton

Re: Pluggable cumulative statistics

Andrei Lepikhov <lepihov@gmail.com>

View thread View on postgr.es
From: Andrei Lepikhov <lepihov@gmail.com>
To: Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-04T03:11:02Z
Lists: pgsql-hackers 
On 6/13/24 14:59, Michael Paquier wrote:
> This will hopefully spark a discussion, and I was looking for answers
> regarding these questions:
> - Should the pgstat_kind_infos array in pgstat.c be refactored to use
> something similar to pgstat_add_kind?
> - How should the persistence of the custom stats be achieved?
> Callbacks to give custom stats kinds a way to write/read their data,
> push everything into a single file, or support both?
> - Should this do like custom RMGRs and assign to each stats kinds ID
> that are set in stone rather than dynamic ones?
It is a feature my extensions (which usually change planning behaviour) 
definitely need. It is a problem to show the user if the extension does 
something or not because TPS smooths the execution time of a single 
query and performance cliffs.
BTW, we have 'labelled DSM segments', which allowed extensions to be 
'lightweight' - not necessarily be loaded on startup, stay backend-local 
and utilise shared resources. It was a tremendous win for me. Is it 
possible to design this extension in the same way?

-- 
regards, Andrei Lepikhov

Commits

  1. injection_points: Add some fixed-numbered statistics

  2. injection_points: Add some cumulative stats for injection points

  3. Add helper routines to retrieve data for custom fixed-numbered pgstats

  4. Introduce pluggable APIs for Cumulative Statistics

  5. Switch PgStat_Kind from an enum to a uint32 type

  6. Improve comment of pgstat_read_statsfile()

  7. Add a new 'F' entry type for fixed-numbered stats in pgstats file

  8. Add PgStat_KindInfo.init_shmem_cb

  9. Use pgstat_kind_infos to write fixed shared statistics

  10. Replace hardcoded identifiers of pgstats file by #defines