SlideShare a Scribd company logo
Производительность запросов в PostgreSQL - шаг за шагом
Илья Космодемьянский
ik@postgresql-consulting.com
План
• Что значит оптимизировать запросы?
• Когда начинать оптимизировать запросы?
• Какие запросы оптимизировать?
• Как оптимизировать запросы?
• Какие запросы бесполезно оптимизировать?
Проблема не новая
Обыкновенно в теории заботятся и
считают хорошим достижением,
если удается повысить
коэффициент полезного действия
винта на 4%, а практика
показывает, что от механика,
машинистов и кочегаров зависят не
4–5%, а 70–75%.
Крылов А.Н.
"Мои воспоминания"
Что значит оптимизировать запросы?
• Задача редко ставится в такой форме
Что значит оптимизировать запросы?
• Задача редко ставится в такой форме
• «Всё плохо»- более типичная постановка
Что значит оптимизировать запросы?
• Задача редко ставится в такой форме
• «Всё плохо»- более типичная постановка
• Медленные запросы просто видны наружу
Что значит оптимизировать запросы?
• Задача редко ставится в такой форме
• «Всё плохо»- более типичная постановка
• Медленные запросы просто видны наружу
• На ненастроенной базе запросы оптимизировать бесполезно
Что значит ненастроенная база?
• Выключен или не настроен автовакуум
• 100500 подключений без pgbouncer
• ...
Алгоритм
• Проверить настройки
• Отобрать запросы для оптимизации
• Оптимизировать запросы
• Повторить
Какие запросы оптимизировать?
• Все подряд - бесполезно
• Отобрать top
• pg_stat_statements
Изучаем top
total time: 06:01:33 (IO: 1.15%)
total queries: 896,507,876 (unique: 377)
report for all databases, version 0.9.2
=============================================================================================================
pos:1 total time: 01:27:08 (24.1%, CPU: 24.4%, IO: 0.0%) calls: 1,038,397 (0.12%) avg_time: 5.03ms (IO: 0.0%)
user: someuser db: somedb rows: 1,754,836 query:
select q.id, q.type, q.servertime, q.clienttime from foo q left outer join bar qq ON q.buzzid = qq.buzzid where qq.yaid
=============================================================================================================
pos:2 total time: 00:28:56 (8.0%, CPU: 8.1%, IO: 0.0%) calls: 120,782,681 (13.47%) avg_time: 0.01ms (IO: 0.0%)
user: someuser db: somedb rows: 557,454,570 query:
select seqid, id, name, notes from bar where pvid = $1 order by id asc
https://github.com/PostgreSQL-Consulting/pg-utils/tree/master/sql/global_reports
Что такое "запрос работает медленно?"
• Запрос работает 123,0 ms
Что такое "запрос работает медленно?"
• Запрос работает 123,0 ms
• Запрос работает 7300,0 ms
Что такое "запрос работает медленно?"
• Запрос работает 123,0 ms
• Запрос работает 7300,0 ms
• Запрос работает 3 min
Что такое "запрос работает медленно?"
• Запрос работает 123,0 ms
• Запрос работает 7300,0 ms
• Запрос работает 3 min
• Запрос работает 0.12 ms
Более правильный подход
• Как часто исполняется запрос
Более правильный подход
• Как часто исполняется запрос
• Какое время отклика мы считаем приемлемым
Более правильный подход
• Как часто исполняется запрос
• Какое время отклика мы считаем приемлемым
• Каков характер нагрузки на базе?
Более правильный подход
• Как часто исполняется запрос
• Какое время отклика мы считаем приемлемым
• Каков характер нагрузки на базе?
• Какой процент ресурсов базы занимает данный запрос
На чем расходуется время при выполнении запроса
• Передача запроса от клиента (НЕ СМЕШНО!)
На чем расходуется время при выполнении запроса
• Передача запроса от клиента (НЕ СМЕШНО!)
• Парсинг
На чем расходуется время при выполнении запроса
• Передача запроса от клиента (НЕ СМЕШНО!)
• Парсинг
• Оптимизация
На чем расходуется время при выполнении запроса
• Передача запроса от клиента (НЕ СМЕШНО!)
• Парсинг
• Оптимизация
• Исполнение
На чем расходуется время при выполнении запроса
• Передача запроса от клиента (НЕ СМЕШНО!)
• Парсинг
• Оптимизация
• Исполнение
• Возврат результатов
Передача запроса от клиента
select id, name, from table id in(312,3443,543,4,76,13,78,98,090,435,565,
2317,1145,76777,23,5678,776,9869,3242,65645,2423,43221,
10,4545,320,59,298,405,47832,5497579,5349934,286438,
5489584,2737284728,43,7б,4б8,3,854,2094,3293826,4773,
394394,5720853,403059,84885,.................
EXPLAIN
PREPARE query(int, int) AS SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo;
EXPLAIN ANALYZE EXECUTE query(100, 200);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=9.54..9.54 rows=1 width=8) (actual time=0.156..0.161 rows=11 loops=1)
Group Key: foo
-> Index Scan using test_pkey on test (cost=0.29..9.29 rows=50 width=8) (actual time=0.039..0.091 rows=99 loops=1)
Index Cond: ((id > $1) AND (id < $2))
Planning time: 0.197 ms
Execution time: 0.225 ms
(6 rows)
pg@pglect01:~/dellstore2-normal-1.0> psql dellstore2 -c ’explain (analyze on, buffers on) select count(*) from customers’
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
Aggregate (cost=738.00..738.01 rows=1 width=0) (actual time=8.357..8.357 rows=1 loops=1)
Buffers: shared hit=488
-> Seq Scan on customers (cost=0.00..688.00 rows=20000 width=0) (actual time=0.026..5.728 rows=20000 loops=1)
Buffers: shared hit=488
Total runtime: 8.607 ms
(5 rows)
Почему не используетеся индекс?
• Собрана-ли статистика?
• Ускорит-ли индекс исполнение запроса?
• Правильно-ли написан запрос? (where counter + 1 = 46)
Почему join работает медленно?
• Какой тип используется?
• Есть-ли индексы?
• Достаточно-ли памяти?
Длинный IN (очень любят ORM)
1. SELECT * FROM test WHERE id<10000
1.2ms
2. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 10)
2.1ms
3. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 100)
6ms
4. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 1000)
38ms
5. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 10000)
380ms (и далее линейно от длинны массива)
IN (1,...100)
explain analyze select * from test where id<10000 and val IN (1,...100);
QUERY PLAN
--------------------------------------------------------------------------------------------------
Index Scan using test_pkey on test (cost=0.43..1666.85 rows=10
width=140) (actual time=0.448..5.602 rows=16 loops=1)
Index Cond: (id < 10000)
Filter: (val = ANY (’{1,...100}’::integer[]))
Rows Removed by Filter: 9984
Длинный IN (hash join)
explain select count(*) from test JOIN (VALUES (1),...,(10)) AS v(val) USING (val) where id<10000;
QUERY PLAN
------------------------------------------------------------------------
Aggregate (cost=497.65..497.66 rows=1 width=0)
-> Hash Join (cost=0.69..497.65 rows=1 width=0)
Hash Cond: (test.val = "*VALUES*".column1)
-> Index Scan using test_pkey on test (cost=0.43..461.22
rows=9645 width=4)
Index Cond: (id < 10000)
-> Hash (cost=0.12..0.12 rows=10 width=4)
-> Values Scan on "*VALUES*" (cost=0.00..0.12 rows=10 width=4)
Длинный IN (Итоги с hash join)
1. SELECT * FROM test WHERE id<10000
1.2ms
2. JOIN (VALUES (1),...,(10))
1.6ms (было 2.1ms)
3. JOIN (VALUES (1),...,(100))
2ms (было 6ms)
4. JOIN (VALUES (1),...,(1000))
3.9ms (было 38ms)
5. JOIN (VALUES (1),...,(10000))
10ms (было 380ms)
"Этот запрос не будет работать быстро никогда"
• count(*)
• join на 300 таблиц
• Запрос возвращает клиенту 1 000 000 000 строк
• Все это серьезные причины для переделки бизнес-логики
Вопросы?
ik@postgresql-consulting.com

More Related Content

PPT
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...
PDF
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)
PDF
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...
PDF
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)
PDF
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)
PDF
PostgreSQL - Ups, DevOps..., Алексей Лесовский (PostgreSQL-Consulting)
PPTX
Mysql vs postgresql
PPTX
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)
Основы индексирования и расширенные возможности EXPLAIN в MySQL / Василий Лук...
Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)
PostgreSQL - Ups, DevOps..., Алексей Лесовский (PostgreSQL-Consulting)
Mysql vs postgresql
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)

What's hot (20)

PDF
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...
PDF
PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Po...
PPTX
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)
PDF
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)
PDF
Современная операционная система: что надо знать разработчику / Александр Кри...
PDF
Практика совместного использования Lua и C в opensource спам-фильтре Rspamd /...
PPTX
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)
PPTX
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...
PDF
Реализация восстановления после аварий / Сергей Бурладян (Avito)
PDF
Семантическое ядро рунета - высоконагруженная сontent-based рекомендательная ...
PDF
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...
PDF
nginx.CHANGES.2015 / Игорь Сысоев, Валентин Бартенев (Nginx)
PDF
My talk at Highload++ 2015
PDF
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...
PDF
Чему мы научились разрабатывая микросервисы?
PPTX
Оптимизация работы с данными в мобильных приложениях / Святослав Иванов, Артё...
PPTX
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)
PDF
Дмитрий Новиков - Tarantool в Badoo
PDF
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...
PDF
Оптимизация программ для современных процессоров и Linux, Александр Крижановс...
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...
PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Po...
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)
Современная операционная система: что надо знать разработчику / Александр Кри...
Практика совместного использования Lua и C в opensource спам-фильтре Rspamd /...
Как устроена MySQL-репликация / Андрей Аксенов (Sphinx)
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...
Реализация восстановления после аварий / Сергей Бурладян (Avito)
Семантическое ядро рунета - высоконагруженная сontent-based рекомендательная ...
Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...
nginx.CHANGES.2015 / Игорь Сысоев, Валентин Бартенев (Nginx)
My talk at Highload++ 2015
Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...
Чему мы научились разрабатывая микросервисы?
Оптимизация работы с данными в мобильных приложениях / Святослав Иванов, Артё...
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)
Дмитрий Новиков - Tarantool в Badoo
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...
Оптимизация программ для современных процессоров и Linux, Александр Крижановс...
Ad

Viewers also liked (12)

PDF
Как понять, что происходит на сервере? / Александр Крижановский (NatSys Lab.,...
PDF
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...
PPTX
Как устроен поиск / Андрей Аксенов (Sphinx)
PDF
С чего начать внедрение Hadoop в компании / Алексей Еремихин (Badoo)
PPTX
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...
PPTX
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...
PDF
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)
PDF
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...
PDF
Бинарные (файловые) хранилища: страшная сказка с мрачным концом / Даниил Подо...
PDF
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...
PDF
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)
PDF
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)
Как понять, что происходит на сервере? / Александр Крижановский (NatSys Lab.,...
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...
Как устроен поиск / Андрей Аксенов (Sphinx)
С чего начать внедрение Hadoop в компании / Алексей Еремихин (Badoo)
Поддержка высоконагруженного проекта: мониторинг, резервирование, обслуживани...
Какие бывают провайдеры услуг дата-центров и как выбрать оптимальный? / Игорь...
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...
Бинарные (файловые) хранилища: страшная сказка с мрачным концом / Даниил Подо...
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)
Ad

Similar to Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянский (PostgreSQL-Consulting.com) (20)

PDF
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
PDF
Как читать и интерпретировать вывод команды EXPLAIN
PDF
PostgreSQL performance recipes
PDF
Адаптивная оптимизация запросов в реляционных СУБД / Олег Иванов (Postgres Pr...
PDF
Парсим CSS: performance tips & tricks
PDF
Парсим CSS
PDF
Иван Фролков
PPTX
Автотестирование АБС. Конвейер разработки, конвейер данных, конвейер выполнения
PDF
CodeFest 2014. Макаров Н. — Selenium Grid. OK Version
PDF
Всеволод Поляков "История одного мониторинга"
PDF
Андрей Аксёнов, Sphinx Technologies Inc.
PPTX
Sphinx 2013
PDF
Сверхоптимизация кода на Python
PDF
Сверхоптимизация кода на Python
PDF
Современному хайлоду - современные решения: MySQL 8.0 и улучшения Percona
PDF
Введение в машинное обучение. Кластеризация (Bitworks Software, Кирилл Жданов)
PDF
Введение в машинное обучение. Кластеризация (Bitworks Software, Кирилл Жданов)
PPTX
ObjectManager, или как работать с большим количеством объектов на карте, Мари...
PDF
Архитектура кода нового 2ГИС Web API или куда мы дели MVC
PDF
Moscow Python Conf 2016. Почему 100% покрытие это плохо?
#RuPostgresLive 4: как писать и читать сложные SQL-запросы
Как читать и интерпретировать вывод команды EXPLAIN
PostgreSQL performance recipes
Адаптивная оптимизация запросов в реляционных СУБД / Олег Иванов (Postgres Pr...
Парсим CSS: performance tips & tricks
Парсим CSS
Иван Фролков
Автотестирование АБС. Конвейер разработки, конвейер данных, конвейер выполнения
CodeFest 2014. Макаров Н. — Selenium Grid. OK Version
Всеволод Поляков "История одного мониторинга"
Андрей Аксёнов, Sphinx Technologies Inc.
Sphinx 2013
Сверхоптимизация кода на Python
Сверхоптимизация кода на Python
Современному хайлоду - современные решения: MySQL 8.0 и улучшения Percona
Введение в машинное обучение. Кластеризация (Bitworks Software, Кирилл Жданов)
Введение в машинное обучение. Кластеризация (Bitworks Software, Кирилл Жданов)
ObjectManager, или как работать с большим количеством объектов на карте, Мари...
Архитектура кода нового 2ГИС Web API или куда мы дели MVC
Moscow Python Conf 2016. Почему 100% покрытие это плохо?

More from Ontico (20)

PDF
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
PDF
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
PPTX
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
PDF
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
PDF
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
PDF
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PDF
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
PDF
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
PPTX
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
PPTX
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
PDF
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
PPTX
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
PPTX
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
PDF
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
PPT
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
PPTX
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
PPTX
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
PPTX
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
PPTX
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
PDF
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...

Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянский (PostgreSQL-Consulting.com)

  • 1. Производительность запросов в PostgreSQL - шаг за шагом Илья Космодемьянский ik@postgresql-consulting.com
  • 2. План • Что значит оптимизировать запросы? • Когда начинать оптимизировать запросы? • Какие запросы оптимизировать? • Как оптимизировать запросы? • Какие запросы бесполезно оптимизировать?
  • 3. Проблема не новая Обыкновенно в теории заботятся и считают хорошим достижением, если удается повысить коэффициент полезного действия винта на 4%, а практика показывает, что от механика, машинистов и кочегаров зависят не 4–5%, а 70–75%. Крылов А.Н. "Мои воспоминания"
  • 4. Что значит оптимизировать запросы? • Задача редко ставится в такой форме
  • 5. Что значит оптимизировать запросы? • Задача редко ставится в такой форме • «Всё плохо»- более типичная постановка
  • 6. Что значит оптимизировать запросы? • Задача редко ставится в такой форме • «Всё плохо»- более типичная постановка • Медленные запросы просто видны наружу
  • 7. Что значит оптимизировать запросы? • Задача редко ставится в такой форме • «Всё плохо»- более типичная постановка • Медленные запросы просто видны наружу • На ненастроенной базе запросы оптимизировать бесполезно
  • 8. Что значит ненастроенная база? • Выключен или не настроен автовакуум • 100500 подключений без pgbouncer • ...
  • 9. Алгоритм • Проверить настройки • Отобрать запросы для оптимизации • Оптимизировать запросы • Повторить
  • 10. Какие запросы оптимизировать? • Все подряд - бесполезно • Отобрать top • pg_stat_statements
  • 11. Изучаем top total time: 06:01:33 (IO: 1.15%) total queries: 896,507,876 (unique: 377) report for all databases, version 0.9.2 ============================================================================================================= pos:1 total time: 01:27:08 (24.1%, CPU: 24.4%, IO: 0.0%) calls: 1,038,397 (0.12%) avg_time: 5.03ms (IO: 0.0%) user: someuser db: somedb rows: 1,754,836 query: select q.id, q.type, q.servertime, q.clienttime from foo q left outer join bar qq ON q.buzzid = qq.buzzid where qq.yaid ============================================================================================================= pos:2 total time: 00:28:56 (8.0%, CPU: 8.1%, IO: 0.0%) calls: 120,782,681 (13.47%) avg_time: 0.01ms (IO: 0.0%) user: someuser db: somedb rows: 557,454,570 query: select seqid, id, name, notes from bar where pvid = $1 order by id asc https://github.com/PostgreSQL-Consulting/pg-utils/tree/master/sql/global_reports
  • 12. Что такое "запрос работает медленно?" • Запрос работает 123,0 ms
  • 13. Что такое "запрос работает медленно?" • Запрос работает 123,0 ms • Запрос работает 7300,0 ms
  • 14. Что такое "запрос работает медленно?" • Запрос работает 123,0 ms • Запрос работает 7300,0 ms • Запрос работает 3 min
  • 15. Что такое "запрос работает медленно?" • Запрос работает 123,0 ms • Запрос работает 7300,0 ms • Запрос работает 3 min • Запрос работает 0.12 ms
  • 16. Более правильный подход • Как часто исполняется запрос
  • 17. Более правильный подход • Как часто исполняется запрос • Какое время отклика мы считаем приемлемым
  • 18. Более правильный подход • Как часто исполняется запрос • Какое время отклика мы считаем приемлемым • Каков характер нагрузки на базе?
  • 19. Более правильный подход • Как часто исполняется запрос • Какое время отклика мы считаем приемлемым • Каков характер нагрузки на базе? • Какой процент ресурсов базы занимает данный запрос
  • 20. На чем расходуется время при выполнении запроса • Передача запроса от клиента (НЕ СМЕШНО!)
  • 21. На чем расходуется время при выполнении запроса • Передача запроса от клиента (НЕ СМЕШНО!) • Парсинг
  • 22. На чем расходуется время при выполнении запроса • Передача запроса от клиента (НЕ СМЕШНО!) • Парсинг • Оптимизация
  • 23. На чем расходуется время при выполнении запроса • Передача запроса от клиента (НЕ СМЕШНО!) • Парсинг • Оптимизация • Исполнение
  • 24. На чем расходуется время при выполнении запроса • Передача запроса от клиента (НЕ СМЕШНО!) • Парсинг • Оптимизация • Исполнение • Возврат результатов
  • 25. Передача запроса от клиента select id, name, from table id in(312,3443,543,4,76,13,78,98,090,435,565, 2317,1145,76777,23,5678,776,9869,3242,65645,2423,43221, 10,4545,320,59,298,405,47832,5497579,5349934,286438, 5489584,2737284728,43,7б,4б8,3,854,2094,3293826,4773, 394394,5720853,403059,84885,.................
  • 26. EXPLAIN PREPARE query(int, int) AS SELECT sum(bar) FROM test WHERE id > $1 AND id < $2 GROUP BY foo; EXPLAIN ANALYZE EXECUTE query(100, 200); QUERY PLAN ------------------------------------------------------------------------------------------------------------------------ HashAggregate (cost=9.54..9.54 rows=1 width=8) (actual time=0.156..0.161 rows=11 loops=1) Group Key: foo -> Index Scan using test_pkey on test (cost=0.29..9.29 rows=50 width=8) (actual time=0.039..0.091 rows=99 loops=1) Index Cond: ((id > $1) AND (id < $2)) Planning time: 0.197 ms Execution time: 0.225 ms (6 rows) pg@pglect01:~/dellstore2-normal-1.0> psql dellstore2 -c ’explain (analyze on, buffers on) select count(*) from customers’ QUERY PLAN ------------------------------------------------------------------------------------------------------------------- Aggregate (cost=738.00..738.01 rows=1 width=0) (actual time=8.357..8.357 rows=1 loops=1) Buffers: shared hit=488 -> Seq Scan on customers (cost=0.00..688.00 rows=20000 width=0) (actual time=0.026..5.728 rows=20000 loops=1) Buffers: shared hit=488 Total runtime: 8.607 ms (5 rows)
  • 27. Почему не используетеся индекс? • Собрана-ли статистика? • Ускорит-ли индекс исполнение запроса? • Правильно-ли написан запрос? (where counter + 1 = 46)
  • 28. Почему join работает медленно? • Какой тип используется? • Есть-ли индексы? • Достаточно-ли памяти?
  • 29. Длинный IN (очень любят ORM) 1. SELECT * FROM test WHERE id<10000 1.2ms 2. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 10) 2.1ms 3. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 100) 6ms 4. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 1000) 38ms 5. SELECT * FROM test WHERE id<10000 AND val IN (список от 1 до 10000) 380ms (и далее линейно от длинны массива)
  • 30. IN (1,...100) explain analyze select * from test where id<10000 and val IN (1,...100); QUERY PLAN -------------------------------------------------------------------------------------------------- Index Scan using test_pkey on test (cost=0.43..1666.85 rows=10 width=140) (actual time=0.448..5.602 rows=16 loops=1) Index Cond: (id < 10000) Filter: (val = ANY (’{1,...100}’::integer[])) Rows Removed by Filter: 9984
  • 31. Длинный IN (hash join) explain select count(*) from test JOIN (VALUES (1),...,(10)) AS v(val) USING (val) where id<10000; QUERY PLAN ------------------------------------------------------------------------ Aggregate (cost=497.65..497.66 rows=1 width=0) -> Hash Join (cost=0.69..497.65 rows=1 width=0) Hash Cond: (test.val = "*VALUES*".column1) -> Index Scan using test_pkey on test (cost=0.43..461.22 rows=9645 width=4) Index Cond: (id < 10000) -> Hash (cost=0.12..0.12 rows=10 width=4) -> Values Scan on "*VALUES*" (cost=0.00..0.12 rows=10 width=4)
  • 32. Длинный IN (Итоги с hash join) 1. SELECT * FROM test WHERE id<10000 1.2ms 2. JOIN (VALUES (1),...,(10)) 1.6ms (было 2.1ms) 3. JOIN (VALUES (1),...,(100)) 2ms (было 6ms) 4. JOIN (VALUES (1),...,(1000)) 3.9ms (было 38ms) 5. JOIN (VALUES (1),...,(10000)) 10ms (было 380ms)
  • 33. "Этот запрос не будет работать быстро никогда" • count(*) • join на 300 таблиц • Запрос возвращает клиенту 1 000 000 000 строк • Все это серьезные причины для переделки бизнес-логики