Re: Preserve index stats during ALTER TABLE ... TYPE ...
| От | Bertrand Drouvot |
|---|---|
| Тема | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Дата | |
| Msg-id | aPXVCORcrKouLtkD@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
| Ответ на | Re: Preserve index stats during ALTER TABLE ... TYPE ... (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Preserve index stats during ALTER TABLE ... TYPE ...
|
| Список | pgsql-hackers |
Hi, On Mon, Oct 20, 2025 at 10:53:37AM +0900, Michael Paquier wrote: > 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. Okay. > 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. Exactly, and that's one of the reasons why the "Split index and table statistics into different types of stats" work ([1]) started. > 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. Yeah, but maybe it would make more sense to look at this once the relfilenode stats one ([2]) is done? (see [3]). [1]: https://www.postgresql.org/message-id/f572abe7-a1bb-e13b-48c7-2ca150546822%40gmail.com [2]: https://www.postgresql.org/message-id/flat/ZlGYokUIlERemvpB@ip-10-97-1-34.eu-west-3.compute.internal [3]: https://www.postgresql.org/message-id/20230105002733.ealhzubjaiqis6ua%40awork3.anarazel.de Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: