Re: Preserve index stats during ALTER TABLE ... TYPE ...
| От | Sami Imseih |
|---|---|
| Тема | Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Дата | |
| Msg-id | CAA5RZ0sxumm6fsOSzQDF-KRkfNvn9t=KqwygEnHZQt-PMPNdjg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Preserve index stats during ALTER TABLE ... TYPE ... (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Preserve index stats during ALTER TABLE ... TYPE ...
Re: Preserve index stats during ALTER TABLE ... TYPE ... |
| Список | pgsql-hackers |
>> 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
В списке pgsql-hackers по дате отправления: