На память - оптимизация базы

[beldmit]

Запрос для поиска пропущенных в базе индексов.

SELECT relname, idx_scan, seq_scan, seq_tup_read
FROM pg_stat_user_tables
ORDER BY seq_tup_read DESC;

И вообще интересная презентация.

Comments

[hydrobiont.livejournal.com]

https://github.com/PostgreSQL-Consulting/pg-utils/blob/master/sql/table_index_write_activity.sql

(можешь дополнить seq_tup_read если хочешь, но у нас для этого https://github.com/PostgreSQL-Consulting/pg-utils/blob/master/sql/table_disk_activity.sql - оно чаще в таком виде бывает нужно)

[astarsan.livejournal.com]

Если уж на то пошло то
https://github.com/PostgreSQL-Consulting/pg-utils/blob/master/sql/seq_scan_tables.sql
;)

[hettie-lz.livejournal.com]

ой, только не изобретайте, пожалуйста, велосипед автоматический создатель пропущенных индексов! Это мой ночной кошмар :))

[beldmit.livejournal.com]

Не буду. Но этот запрос мне пару раз служил хорошую службу.

[beldmit.livejournal.com]

Мы тут в своём проекте включили лог запросов. Столько интересного узнали...

[astarsan.livejournal.com]

Это всегда так. Причем обычно самые проблемные места оказываются там где граблей никто не ожидал.

[beldmit.livejournal.com]

Ну, у нас нагрузка копеечная, поэтому тупо нашлись внеплановые ненужные запросы по штуке на домен.

[hettie-lz.livejournal.com]

Конечно! Это очень правильный SQL, мы его даже сохраняли в специальном пакете функций. Но я жутко пугана самой идеей автоматизации всего - один товарищ на моей прежней работе этим страдал :)))

[hettie-lz.livejournal.com]

Полный?

[beldmit.livejournal.com]

Полный

[hettie-lz.livejournal.com]

да, это обычно очень большой eye -opener :)