>> Hence, the planner may decide >> to treat a given index differently (doesn't it? Tuple width or >> whole-row references come into mind).
> I do think so, yes. The planner may also treat the index differently after ALTER INDEX ... ALTER COLUMN ... SET STATISTICS ...; ANALYZE, but in I am not sure the planner aspect is a good reason to not preserve cumulative stats for an index. In the case where the table is not rewritten, Isn't that a clear case in which stats should be preserved? > > Keeping the past stats may > > actually lead to confusing conclusions when overlapping them with some > > of the new number generated under the new type? Could there be more > > benefits in always resetting them as we do now? > > The issue is that these stats are also exposed at the table level > (idx_scan, last_idx_scan, idx_tup_fetch in pg_stat_all_tables). > That's valuable information for understanding table access patterns > that is currently lost. > > It would make more sense to reset the index stats if table level > stats were tracked independently from the underlying index stats. 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. -- Sami
