Bloom-фильтры в Postgres: скрытый инструмент для оптимизации запросов

В мире разработки и работы с базами данных Bloom-фильтры – это мощный, но малоизвестный инструмент, который может значительно ускорить выполнение запросов и снизить нагрузку на систему. Однако, несмотря на их потенциал, многие разработчики даже не знают, что Postgres поддерживает Bloom-фильтры "из коробки" (функциональность Bloom-фильтров доступна сразу после установки Postgres, при включении соответствующего расширения) через расширение bloom. Bloom-фильтры особенно полезны в ситуациях, когда нужно быстро проверить, принадлежит ли элемент к множеству, или когда требуется оптимизировать запросы с несколькими условиями. Например, они могут ускорить JOIN-запросы, поиск по нескольким столбцам или агрегатные функции. В этой статье мы разберем, что такое Bloom-фильтры, как они работают в Postgres, и в каких случаях их использование может быть полезным. Мы также рассмотрим практические примеры и покажем, как Bloom-фильтры могут помочь в оптимизации запросов.

https://habr.com/ru/companies/ppr/articles/890184/

#postgres #sql #оптимизация_запросов #bloom_filter #оптимизация_запросов_к_базам_данных

9 способов прокачать SQL-запрос: оптимизация для разработчиков

Вы когда-нибудь задумывались, почему некоторые SQL-запросы работают быстро, а другие заставляют ждать вечность? Оптимизация запросов — одна из важнейших задач при работе с базами данных, особенно если речь идет о больших объемах данных. Сегодня мы разберем конкретный пример и покажем, как сделать запрос максимально эффективным.

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

#SQL #оптимизация_запросов_к_базам_данных #базы_данных

Странное поведение планировщика запросов PostgreSQL

В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL . В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов. Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

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

#оптимизация_запросов_postgresql #оптимизация_запросов_к_базам_данных #высокая_производительность #postgresql #временные_таблицы

[Перевод] Как оптимизировать медленные SQL запросы?

Большинство проблем, связанных с БД, во время разработки остаются незамеченными, потому что мы пишем код и проверяем его правильность только при малой "заполненности" нашей БД. Поэтому, когда приложение выкатывается в продакшн, через некоторое время начинают появляться проблемы с производительностью БД, отдельные части приложения начинают работать всё медленнее и медленнее по мере роста самого БД. Как выявить и отладить такие проблемы? В этой статье будет показано решение наиболее распространённых проблем с производительностью БД, вызванных неправильной индексацией. Примеры будут приведены для Postgres, MySQL и SQLite.

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

#sql #sqlite #postgresql #mysql #оптимизация_запросов_к_базам_данных