NetBash.ru

Общие сведения

Чтобы эффективно обслуживать множество клиентов, сервер запускает отдельный «обслуживающий» процесс для каждого клиента
Когда сервер закрывает соединение, он предварительно откатывает любую открытую (незавершённую) транзакцию
При «простом» выполнении запросов клиент посылает текстовую строку запроса, которую сервер сразу же разбирает и выполняет. При «расширенном» выполнении запросов обработка разделяется на несколько этапов: разбор, привязывание значений параметров и исполнение.
Клиент и сервер обмениваются сообщениями используя специальный протокол
Чтобы не потерять синхронизацию в потоке сообщений, и серверы, и клиенты обычно считывают всё сообщение в буфер (его размер определяется счётчиком байт), прежде чем обрабатывать его содержимое. Это позволяет без труда продолжить работу, если возникает ошибка при разборе сообщения.
В расширенном протоколе запросов исполнение команд SQL разделяется на несколько этапов. Состояние между этапами представляется объектами двух типов: подготовленные операторы и порталы
Подготовленный оператор представляет собой результат разбора и семантического анализа текстовой строки запроса. Подготовленный оператор сам по себе не готов для исполнения, так как он может не иметь конкретных значений для параметров. Портал представляет собой готовый к исполнению или уже частично выполненный оператор, в котором заданы все недостающие значения параметров.
Общий цикл выполнения состоит из этапа разбора, на котором из текстовой строки запроса создаётся подготовленный оператор; этапа привязки, на котором из подготовленного оператора и значений для необходимых параметров создаётся портал; и этапа выполнения, на котором исполняется запрос портала.
Обращаться к подготовленным операторам и порталам можно по именам, которые назначаются им при создании. Кроме того, существуют и «безымянные» подготовленные операторы и порталы. Хотя они практически не отличаются от именованных объектов, операции с ними оптимизированы для разового выполнения запроса с последующим освобождением объекта, тогда как операции с именованными объектами оптимизируются в расчёте на многоразовое использование.
Источник: https://postgrespro.ru/docs/postgresql/13/protocol-overview

Этапы запроса и получения результата

1. Подключение клиента ( программы ) к серверу ( postgresql )
2. Проверка синтаксиса запроса и создание дерева разбора
3. После разбора система правил ищет в системных каталогах правила для применения к сформированному дереву разбора, формирует дерево запроса
4. Планировщик/оптимизатор принимает дерево запроса и создает план запроса из наиболее выгодных вариантов, далее передает его исполнителю
5. Исполнитель рекурсивно проходит по дереву обращаясь к системе хранения, выполняет сортировку и соединения ( JOIN ), возвращает полученные строки
Подключения клиентов принмает главный процесс postmaster, пораждает новый серверный процесс, чтобы разделять ресурсы, процессы используют семафоры и разделяемую память
Анализатор при разборе проверяет синтаксис ( gram.y ), лексическую структуру ( scan.l ) запроса ( Unix bison и flex ), если он правильный, строится дерево разбора
Изучение грамматики, описанной в gram.y, следует начать со знакомства с bison
Процедура преобразования принимает дерево разбора от анализатора и выполняет семантический анализ, для понимания к каким фнукциям и операторам, типам данных обращается запрос, после этого создается дерево запроса
Система правил ( между анализатором и планировщиком ) при необходимости изменяет запрос и формирует новое дерево запроса на выходе

Планировщик-оптимизатор

Задача планировщика/оптимизатора построить наилучший план выполнения, выбор наилучшего плана запроса не всегда уместно, т.к. это занимает время. Для выбора разумного плана запроса за приемлимое время, используется генетический оптимизатор, когда кол-во соединений превышает предел
Когда план запроа выбран, строится полноценное дерево планов ( путей ), данное дерево передается исполнителю
Планировщик сканирует каждое отдельное отношение, множество возможных планов, зависит от кол-ва индексов в отношении.
После планов отдельных отношений, если есть соединение отношений, будет рассматриваться планы соединении отношений
Есть несколько типов планов соединений:
Соещинение с вложенным циклом, где правое отношение сканируется один раз для каждой строки, найденной в левом отношении, значения в левом отношении могут использоваться как ключи для сканирования по индексу
Соединение слиянием, где каждое отношение сортируется по атрибутам соединения до начала соединения, затем два отношения сканируются параллельно, объеденяются, формируют строки соединения, каждое отношение сканируется только один раз
соединение по хешу: сначала сканируется правое отношение и формируется хеш-таблица, ключ в которой вычисляется по атрибутам соединения. Затем сканируется левое отношение и по тем же атрибутам в каждой строке вычисляется ключ для поиска в этой хеш-таблице соответствующих строк справа
Подробнее: https://postgrespro.ru/docs/postgresql/15/planner-optimizer
Законченное дерево плана содержит узлы сканирования по индексу или последовательного сканирования базовых отношений, плюс узлы соединения с вложенным циклом, соединения слиянием или соединения по хешу (если требуется), плюс, возможно, узлы дополнительных действий, например, сортировки или вычисления агрегатных функций. Большинство из этих узлов могут дополнительно производить отбор (отбрасывать строки, не удовлетворяющие заданному логическому условию) и расчёты (вычислять производный набор столбцов по значениям заданных столбцов, то есть вычислять скалярные выражения). Одна из задач планировщика — добавить условия отбора из предложения WHERE и вычисления требуемых выходных выражений к наиболее подходящим узлам дерева плана. Источник: https://postgrespro.ru/docs/postgresql/15/planner-optimizer

Исполнитель

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

Источники