Запросы в PostgreSQL: 1. Этапы выполнения

[erogov]

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

Сертификация будет по версии 13, чтобы соответствовать курсам. (Да, сначала мы думали про 12-ю, но поезд уже ушел.)

[PrinceKorwin]

Спасибо огромное за ваши статьи! Они отличный источник вдохновения!

Вы не подскажете где можно подсмотреть на общую архитектуру PostgreSQL?

Что-то типо такого наверное:

[ connection management layer ]

[ session management layer ]

[ query parsing / processing layer ]

[ query cache ]

[ query execution layer ]

[ statistics mgmt] [ query analyzer ] [locking mgmt ]

[ persistence layer ]

[ data cache ] [ block cache ] [ locking mgmt]

[ WAL mgmt] [ .. ]

В академических целях люблю ковыряться в разных БД и делать свои велосипеды :)

[erogov]

Рад, что вдохновляетесь!

Насчет архитектуры. В документации, к сожалению, нет внятного короткого описания. Мы пытались что-то изобразить в DBA1 в темах 4-10. Попробуйте еще посмотреть Вову Бородина (видео https://www.youtube.com/watch?v=ejLzS6rVpkk, слайды https://www.slideshare.net/yandex/postgre-sql-41754731).

[lesovsky]

Посмотрите тут.

[lesovsky]

Но уплощение выполняется только если оно не приведет к появлению в плоском списке более join_collapse_limit элементов (значение параметра по умолчанию — 8). В данном примере при любых значениях параметра, меньших 5, узел JOINEXPR не будет уплощен.

Несколько раз перечитал, мне кажется что первое предложение противоречит второму.
То есть первое предложение говорит "уплощать пока итоговое значение в списке меньше 8".
Второе говорит наоборот "НЕ уплощать пока итоговое значение меньше 5+3"

Все ли верно в цитате? или таки в первом предложении есть лишняя частица "не"?

[erogov]

Алексей, вроде все верно. Во втором предложении «меньше пяти» относится не длине списка, а к значению параметра. А длина там ровно 5, столько узлов в примере.

Но согласен, написал я не очень. Подумаю, как это переформулировать почетче.

[lesovsky]

Всё, понял теперь, спасибо :)

[erogov]

-

[bigtrot]

Вы сказали, что

В PostgreSQL разбор запросов обходится дешево и не влияет на другие процессы.

Какова практическая ценность подготавливать запросы, кроме как защита от sql - инъекций?

[erogov]

Сокращение времени выполнения запросов за счёт того, что часть действий происходит при подготовке. Чем чаще запрос повторяется в одном сеансе, и чем запрос короче, тем сильнее эффект.