HTML-код
- Опубликовано: 16 сен 2024
- Онлайн-опросы неизменно показывают - всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN - основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, - я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
СЛАЙДЫ:
- первая часть (explain): www.slideshare.net/alexius2/explain-82601826
- вторая часть (adv. sql): www.slideshare.net/samokhvalov/rupostgreslive-4-sql
ПОЛЕЗНОЕ:
визуализаторы explain:
- explain.depesz.com/
- tatiyants.com/pev
статьи, слайды:
- очень полезные сайты (Маркус Винанд): modern-sql.com/ и use-the-index-luke.com
- обзор «фишек» современного стандартного SQL use-the-index-luke.com/blog/2015-02/modern-sql
- много про count(..) gist.github.com/begriffs/67839ff18176d5879e77954bfcd38f1f
- Максим Богук, “Как научить слона танцевать Рок-н-ролл” pgday.ru/presentation/232/5964945ea4142.pdf
Twitter: twitter.com/postgresmen - подписывайтесь!
Ну и на RUclips-канал тоже подписывайтесь, если ещё не.
Важное замечание-дополнение про index only scans!
По поводу последнего примера с рекурсивным CTE. В чате абсолютно верно подсказывали (спасибо, Виктор!). Я упустил очень важное - там в таблице делались UPDATE-ы, когда я готовил датасет и я забыл VACUUM по ней сделать. Автовакуум нас не посещал... Ну и поэтому было много Heap Fetches.
Вот что должно быть в хорошем состоянии, когда вакуум прошёлся недавно, всего 171ms вместо ~800ms, так как на хождение в сами таблицы (heap fetches) совсем время перестаёт тратиться:
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CTE Scan on t (cost=52.27..54.29 rows=101 width=8) (actual time=0.035..171.033 rows=10000 loops=1)
CTE t
-> Recursive Union (cost=0.42..52.27 rows=101 width=8) (actual time=0.033..165.225 rows=10000 loops=1)
-> Limit (cost=0.42..0.46 rows=1 width=8) (actual time=0.031..0.031 rows=1 loops=1)
-> Index Only Scan using u_post_author_id_created_at on post (cost=0.42..30415.35 rows=1000195 width=8) (actual time=0.031..0.031 rows=1 loops=1)
Heap Fetches: 0
-> Nested Loop (cost=0.42..4.98 rows=10 width=8) (actual time=0.015..0.015 rows=1 loops=10000)
-> WorkTable Scan on t t_1 (cost=0.00..0.20 rows=10 width=8) (actual time=0.000..0.000 rows=1 loops=10000)
-> Limit (cost=0.42..0.46 rows=1 width=8) (actual time=0.014..0.014 rows=1 loops=10000)
-> Index Only Scan using u_post_author_id_created_at on post post_1 (cost=0.42..10974.89 rows=333398 width=8) (actual time=0.013..0.013 rows=1 loops=10000)
Index Cond: (person_id > t_1._person_id)
Heap Fetches: 0
Planning time: 0.357 ms
Execution time: 172.195 ms
И, кстати, эта же проблема мне попортила один из первых примеров, когда я ждал index only scan, а ловил bitmap index & heap scan-ы (ruclips.net/video/7HFecftZ1qM/видео.htmlh18m51s)
Итого: держите автовакуум агрессивно настроенным - не только ради уменьшения раздувания таблиц (bloat), но и для того, чтобы visibility maps были актуальны и index only scan-ы работали эффективно, без кучи heap fetches!
Спасибо за видео! Возможно ли записать ролик с тем как писать процедуры plpgsql с конкретными действиями, а главное показать процесс размышления. Второй год как в разработке.
Спасибо
возможно, сделаем - но на англ тогда уже (postgres.tv)
спасибо за идею
@@RuPostgres No prob!)
видео норм, но голос капец.... и потом еще этот сербок воды на 20 минуте , я не выдержал