>> 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
