From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
Date: | 2025-10-20 06:22:00 |
Message-ID: | aPXVCORcrKouLtkD@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)ip-10-97-1-34(dot)eu-west-3(dot)compute(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-10-20 06:26:24 | Re: using index to speedup add not null constraints to a table |
Previous Message | Bertrand Drouvot | 2025-10-20 06:11:41 | Re: Question about InvalidatePossiblyObsoleteSlot() |