ОБЪЯСНИТЬ И АНАЛИЗИРОВАТЬ

Вы когда-нибудь задумывались, как база данных выбирает использовать ли тот красивый индекс, который вы только что создали? Как только вы нажмете Enter в запросе (скажем, длинном соединении со связанной группой), Планировщик запросов на лету вычисляет десятки стратегий для выполнения запроса и выбирает ту, которая теоретически считается самой быстрой.

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

ОБЪЯСНЯТЬ

Чтобы узнать, как планировщик собирается действовать, просто поместите волшебное слово EXPLAIN в начало вашего запроса.

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

Результатом не будет заказов! Вместо этого вы увидите план на выходе (с примерной статистикой):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

Это говорит нам:

1. Планировщик будет использовать Seq Scan (грубое последовательное чтение всего диска). Плохо, если заказов миллиарды.
2. По оценкам, будет возвращено около 15 строк, и вычисляет «стоимость» в предварительно загруженных циклах ЦП.

ОБЪЯСНИТЬ АНАЛИЗИРОВАТЬ

В то время как EXPLAIN полагается на алгоритмические предположения (основанные на глобальной статистике, вычисленной за последние несколько часов по данным), EXPLAIN ANALYZE фактически выполняет запрос (и ожидает полных логических результатов), сравнивая реальное затраченное время в математически абсолютных терминах.

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

Ура! Здесь вы узнаете, что база данных решила применить сканирование индекса к нашему вторичному индексу idx_orders_cust, что занимает микроскопическое время выполнения в тысячную долю секунды и пропускает миллионы строк на лету.

Ваша очередь

Получение правдивых показателей