https://www.postgresql.org/docs/current/sql-analyze.html

https://public.dalibo.com/exports/conferences/_archives/_2012/201211_explain/understanding_explain.pdf

*************************************************************
1. Обычный EXPLAIN ANALYZE показывает время выполнения, но не всегда объясняет, почему оптимизатор выбрал тот или иной путь. Попробуем расшифровать скрытые подсказки:  

EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM orders WHERE user_id = 100 AND status = 'processed';

Ключевые параметры:  
BUFFERS - об этом параметре мы уже подробно писали (https://t.me/pg_guru/299), показывает, сколько данных было прочитано из кеша/диска;
VERBOSE - раскрывает дополнительные детали, например, имена столбцов.  

Если в выводе видим Buffers: shared hit=1534 read=217, это значит, что 1534 страницы были в кеше, а 217 пришлось читать с диска. Оптимизация может заключаться в увеличении work_mem или добавлении индекса, покрывающего запрос, а вовсе не в переписывании текста самого запроса.

2. PostgreSQL выбирает алгоритм соединения таблиц на основе статистики. Но иногда ей можно помочь и принудительно указать тип JOIN (не всегда рекомендуется!)

SET enable_nestloop = off;
SET enable_hashjoin = on;
SET enable_mergejoin = off;

Когда что использовать:  
Hash Join - хорош для больших несортированных таблиц;
Merge Join - эффективен, если данные уже отсортированы (например, по индексу);
Nested Loop - лучший выбор для маленьких таблиц или когда одна из них сильно фильтруется.  

3. Вместо создания индекса на весь столбец можно оптимизировать место и использовать частичные или покрывающие индексы. Про такие виды индексов мы более подробно уже писали (https://t.me/pg_guru/666).

Частичный индекс (только для "активных" заказов):

CREATE INDEX idx_orders_active ON orders (user_id) 
WHERE status = 'active';

Покрывающий индекс:

CREATE INDEX idx_orders_covering ON orders (user_id) INCLUDE (status);

Если запрос запрашивает только user_id и status, PostgreSQL может выполнить Index Only Scan, вообще не обращаясь к таблице.  

4. Работа с JSONB может быть медленной без правильных индексов.

Создаём GIN-индекс для быстрого поиска по ключам:

CREATE INDEX idx_gin_data ON users USING gin (profile_data);

Мы можем создать индекс по конкретному JSON пути:

CREATE INDEX idx_jsonb_path ON users 
USING gin ((profile_data->'address'->>'city'));

Теперь запросы вроде  

SELECT * FROM users 
WHERE profile_data @> '{"address": {"city": "Moscow"}}';

будут работать гораздо быстрее.  

На этом пока все! Будем развивать данную тему в будущих постах.

Если у вас есть какие-то лайфхаки по оптимизации запросов в PostgreSQL, оставляйте их в комментариях. До связи!