Как один индекс на created_at сократил время ответа API с 12 секунд до 40 мс

«Страница заказов грузится вечность», — такой тикет прилетел в понедельник утром. На проде 800 тысяч записей, а типичный запрос с фильтрацией и сортировкой заставлял менеджеров ждать по 12 секунд. В этой статье разберем, почему стандартный индекс по одному полю не сработал, как EXPLAIN ANALYZE помог найти «бутылочное горлышко» и почему порядок полей в составном индексе имеет решающее значение

https://habr.com/ru/articles/990398/

#PostgreSQL #Django #оптимизация_SQL #индексы #составной_индекс #EXPLAIN_ANALYZE #производительность_БД #backendразработка

PostgreSQL и 1С: как построить систему поиска «тихих убийц» производительности

Стандартный мониторинг часто пропускает «тихих убийц» — запросы, которые по отдельности кажутся нормальными, но в сумме создают аномальную нагрузку на СУБД. В итоге система живет в хрупкой идиллии до первого аврала. В статье — описание универсального способа контроля качества кода и нагрузки на базу без выделенного DBA. Пошагово разберем поиск неоптимальных запросов с помощью pgBadger на живом кейсе.

https://habr.com/ru/articles/986306/

#PostgreSQL #1C #pgBadger #оптимизация #производительность #SQL #индексы #explain_analyze #sequential_scan #администрирование_бд

Как я распилил 1,1 ТБ default-партиции и не уронил прод

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition . Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с . Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит. 44 секунды блокировки: план операции

https://habr.com/ru/articles/977528/

#партиционирование_PostgreSQL #ATTACH_PARTITION #plpgsql #автоматизация_обслуживания_БД #explain_analyze #downtime #advisory_lock #CHECK_constraint #partitioning #database_migrations

Правильный порядок колонок в B-tree индексах PostgreSQL или правило ESR

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности? В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

https://habr.com/ru/articles/911688/

#postgresql #Btree #составной_индекс #многоколонковый_индекс #ESR_правило #оптимизация_запросов #селективность #план_выполнения #explain_analyze #индексный_скан