Существует ли инструмент или метод, чтобы проанализировать Пост-ГРЭС и определить, какие пропавшие без вести индексов должны быть созданы, и какие неиспользованные индексы должны быть удалены? У меня есть немного опыта при выполнении этого с инструментом "профилировщика" для SQLServer, но я не знаю о подобном инструменте, включенном с Пост-ГРЭС.
Метод определения недостающих индексов .... Нет. Но есть некоторые планы сделать это проще в будущем выпуске, например, псевдоиндексы и машиночитаемый EXPLAIN.
В настоящее время вам нужно EXPLAIN ANALYZE
неэффективные запросы, а затем вручную определить лучший маршрут. Некоторые анализаторы журналов, такие как pgFouine , могут помочь определить запросы.
Что касается неиспользуемых индексов, вы можете использовать что-то вроде следующего, чтобы помочь их идентифицировать:
select * from pg_stat_all_indexes where schemaname <> 'pg_catalog';
Это поможет идентифицировать прочитанные, отсканированные, извлеченные кортежи.
Проверить статистику. Начните с pg_stat_user_tables
и pg_stat_user_indexes
.
См. « Сборщик статистики ».
В вики PostgreSQL есть несколько ссылок на сценарии, которые помогут вам найти неиспользуемые индексы. Основной метод заключается в том, чтобы посмотреть на pg_stat_user_indexes
и найти те, где idx_scan
, подсчет того, сколько раз этот индекс использовался для ответа на запросы, равен нулю или, по крайней мере, очень мал . Если приложение изменилось, а ранее использовавшийся индекс, вероятно, не сейчас, вам иногда нужно запускать pg_stat_reset ()
, чтобы вернуть всю статистику обратно к 0, а затем собрать новые данные; вы можете сохранить текущие значения для всего и вместо этого вычислить дельту, чтобы выяснить это.
Пока нет хороших инструментов, которые предлагали бы отсутствующие индексы. Один из подходов состоит в том, чтобы регистрировать выполняемые вами запросы и анализировать, выполнение каких из них занимает много времени, с помощью инструмента анализа журнала запросов, такого как pgFouine или pqa. См. « Регистрация сложных запросов » для получения дополнительной информации.
Другой подход заключается в просмотре pg_stat_user_tables
и поиске таблиц, которые имеют большое количество последовательных сканирований против них, где seq_tup_fetch
большой.Когда используется индекс, вместо этого увеличивается счетчик idx_fetch_tup
. Это может подсказать вам, когда таблица недостаточно хорошо проиндексирована, чтобы отвечать на запросы к ней.
Собственно выяснить, какие столбцы следует индексировать? Обычно это снова приводит к анализу журнала запросов.