On Thu, Oct 16, 2025 at 03:39:59PM -0500, Sami Imseih wrote: > This sounds like a good enhancement. This will also take care of the > index stats being preserved on a table in the case an index is dropped. > > But that means we will need some new fields to aggregate index access > in PgStat_StatTabEntry, which may not be so good in > terms of memory and performance.
Putting aside the should-we-preserve-index-stats-on-relation-rewrite problem for a minute. FWIW, I think that aiming at less memory per entry is better in the long term, because we are that it's going to be cheaper. One thing that's been itching me quite a bit with pgstat_relation.c lately is that PgStat_StatTabEntry is being used by both tables and indexes, but we don't care about the most of its fields for indexes. The ones I can see as used for indexes are: - blocks_hit - blocks_fetched - reset_time - tuples_returned - tuples_fetched - lastscan - numscan This means that we don't care about the business around HOT, vacuum (we could care about the vacuum timings for individual index cleanups), analyze, live/dead tuples. It may be time to do a clean split, even if the current state of business in pgstat.h is a kind of historical thing. -- Michael
signature.asc
Description: PGP signature
