5 советов по PostgreSQL, которыми большинство разработчиков никогда не пользуется
Используйте условные/частичные индексы. Вместо индексации всего столбца индексируйте только строки, которые реально используются в ваших запросах (например, status = 'active'). Такой индекс меньше, поиск быстрее, а места на диске требуется меньше.
Минимизируйте N+1-запросы. Вместо выполнения отдельного запроса внутри цикла получите все данные сразу с помощью JOIN или одного запроса с IN(). Это одна из самых распространённых причин проблем с производительностью.
Используйте CTE (WITH), чтобы сделать сложные запросы более читаемыми, а рекурсивные CTE — для удобной работы с иерархическими данными: деревьями категорий, организационными структурами и т. д.
В PostgreSQL нет планировщика событий, как в MySQL, но похожее поведение можно реализовать с помощью триггеров + LISTEN/NOTIFY, а для запланированных задач использовать расширение pg_cron.
Прежде чем оптимизировать запрос вслепую, запустите EXPLAIN ANALYZE и посмотрите, где на самом деле тратится время. Ваше предположение часто оказывается неверным — реальный план выполнения покажет, где именно нужен индекс.
👉 @SQLPortal
Используйте условные/частичные индексы. Вместо индексации всего столбца индексируйте только строки, которые реально используются в ваших запросах (например, status = 'active'). Такой индекс меньше, поиск быстрее, а места на диске требуется меньше.
Минимизируйте N+1-запросы. Вместо выполнения отдельного запроса внутри цикла получите все данные сразу с помощью JOIN или одного запроса с IN(). Это одна из самых распространённых причин проблем с производительностью.
Используйте CTE (WITH), чтобы сделать сложные запросы более читаемыми, а рекурсивные CTE — для удобной работы с иерархическими данными: деревьями категорий, организационными структурами и т. д.
В PostgreSQL нет планировщика событий, как в MySQL, но похожее поведение можно реализовать с помощью триггеров + LISTEN/NOTIFY, а для запланированных задач использовать расширение pg_cron.
Прежде чем оптимизировать запрос вслепую, запустите EXPLAIN ANALYZE и посмотрите, где на самом деле тратится время. Ваше предположение часто оказывается неверным — реальный план выполнения покажет, где именно нужен индекс.
👉 @SQLPortal