такая, как описано выше, то можно подумать).
Косвенно — по избыточной (в разы) нагрузке от autovacuum по сравнению с ожидаемой.
Прямо — запросами на основании:
SELECT MIN(ctid) -- тут может быть полезно их распределение, кстати
FROM medium_table
WHERE created_at > '<последний месяц>'; -- или id > чего-то подобного и т.п.
т.е. если такие записи раскиданы по таблице куда сильнее, чем ожидается.
> есть ссылка на чтиво?
Хмм.... сходу нет.
(Ещё вспомнил) Что касается патологических случаев — кажется, тот же @Komzpa (и, вроде, прямо здесь) описывал и другой подобный — когда нагрузка такая, что индексы "раздуваются" практически неограниченно (в 10-100 раз больше, чем они должны бы быть для таблицы такого размера). Тут партиционирование может очень помочь с обслуживанием (регулярной реиндексацией).
получается, если нарушается закономерность, что ctid должен расти с created_at. т.е. если новые строки получают ctid сильно меньше максимального?
Ну да, и если их относительно много слишком близко к "физическому" началу таблицы (в том, что пара записей попала не туда, вряд ли есть что-то страшное).
мерси бакуп)
Про "пухнущие" индексы — вот ссылка: https://t.me/pgsql/146282 А про предыдущий случай — кажется, вот этот thread: https://www.postgresql.org/message-id/CAC8Q8tLBeAxR%2BBXWuKK%2BHP5m8tEVYn270CVrDvKXt%3D0PkJTY9g%40mail.gmail.com
Обсуждают сегодня