Re: Preserve index stats during ALTER TABLE ... TYPE ...
| От | Michael Paquier |
|---|---|
| Тема | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Дата | |
| Msg-id | aPWWIdZwunK-Knyd@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Preserve index stats during ALTER TABLE ... TYPE ... (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: Preserve index stats during ALTER TABLE ... TYPE ...
|
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: