Re: Tracking last scan time

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Tracking last scan time
Дата
Msg-id CA+OCxoxFFLz+nQteim-Fx=2_eFx0hj2AY8PKwEbE11Y0KRBPug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tracking last scan time  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Tracking last scan time  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers


On Wed, 24 Aug 2022 at 15:18, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Aug 23, 2022 at 10:55:09AM +0100, Dave Page wrote:
> Often it is beneficial to review one's schema with a view to removing indexes
> (and sometimes tables) that are no longer required. It's very difficult to
> understand when that is the case by looking at the number of scans of a
> relation as, for example, an index may be used infrequently but may be critical
> in those times when it is used.
>
> The attached patch against HEAD adds optional tracking of the last scan time
> for relations. It updates pg_stat_*_tables with new last_seq_scan and
> last_idx_scan columns, and pg_stat_*_indexes with a last_idx_scan column to
> help with this.

Would it be simpler to allow the sequential and index scan columns to be
cleared so you can look later to see if it is non-zero?  Should we allow
arbitrary clearing of stat columns?

I don't think so, because then stat values wouldn't necessarily correlate with each other, and you wouldn't know when any of them were last reset unless we started tracking each individual reset. At least now you can see when they were all reset, and you know they were reset at the same time.
 
--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inconsistencies around defining FRONTEND
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Tracking last scan time