Перейти к основному содержимому

Дерево запросов

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

Система правил расположена между синтаксическим анализатором и планировщиком. Она принимает вывод синтаксического анализатора, одно дерево запросов, и пользовательские правила перезаписывания, которые также являются деревьями запросов с некоторой дополнительной информацией, и создает ноль или более деревьев запросов в результате. Таким образом, его ввод и вывод всегда являются вещами, которые сам синтаксический анализатор мог бы произвести, и поэтому все, что он видит, в принципе представимо в виде оператора SQL.

Итак, что такое дерево запросов? Это внутреннее представление оператора SQL, где отдельные части, из которых он построен, хранятся отдельно. Эти деревья запросов могут отображаться в журнале сервера, если установить параметры конфигурации debug_print_parse, debug_print_rewritten или debug_print_plan. Действия правил также хранятся в виде деревьев запросов в системном каталоге pg_rewrite. Они не отформатированы так же, как вывод журнала, но содержат точно такую же информацию.

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

При чтении представлений деревьев запросов на языке SQL в этом разделе необходимо уметь определять части, на которые разбивается оператор при его преобразовании в структуру дерева запросов. Части дерева запроса:

  • тип команды – простое значение, указывающее, какая команда (SELECT, INSERT, UPDATE, DELETE) произвела дерево запросов.

  • список отношений – список отношений, которые используются в запросе. В операторе SELECT это отношения, указанные после ключевого слова FROM.

    Каждый элемент списка отношений представляет таблицу или представление и говорит, с каким именем они упоминаются в других частях запроса. В дереве запросов записи таблицы диапазона ссылаются по номеру, а не по имени, поэтому здесь не имеет значения, есть ли дублирующиеся имена, как это было бы в инструкции SQL. Это может произойти после объединения таблиц диапазона правил. Примеры в этом разделе такой ситуации не будут иметь.

  • результативное отношение – индекс в таблицу диапазонов, который идентифицирует отношение, где результаты запроса будут размещены.

    SELECT запросы не имеют результирующего отношения. (Особый случай с SELECT INTO почти идентичен CREATE TABLE, за которым следует INSERT ... SELECT, и здесь отдельно не обсуждается.)

    Для команд INSERT, UPDATE и DELETE, результативным отношением является таблица (или представление), где должны произойти изменения.

  • целевой список – список выражений, которые определяют результат запроса. В случае с SELECT, эти выражения формируют окончательный вывод запроса. Они соответствуют выражениям между ключевыми словами SELECT и FROM. (* - это просто сокращение для всех имен столбцов отношения. Он расширяется парсером до отдельных столбцов, поэтому система правил никогда его не видит.)

    Команды DELETE не нуждаются в обычном целевом списке, поскольку они не дают никакого результата. Вместо этого планировщик добавляет специальную запись CTID в пустой целевой список, чтобы исполнитель мог найти строку, которую нужно удалить. (CTID добавляется, когда отношение-результат является обычной таблицей. Если это представление, вместо этого системой правил добавляется переменная всей строки, как описано в разделе «Обновление представления».)

    Для команд INSERT список назначения описывает новые строки, которые должны быть включены в отношение результата. Он состоит из выражений в предложении VALUES или тех, что находятся в предложении SELECT в INSERT ... SELECT. Первый шаг процесса переписывания добавляет элементы списка назначения для любых столбцов, которым не было присвоено значение исходной командой, но у которых есть значения по умолчанию. Все оставшиеся столбцы (без заданного значения или значения по умолчанию) будут заполнены планировщиком с помощью выражения постоянного нуля.

    Для команд UPDATE список назначения описывает новые строки, которые должны заменить старые. В системе правил он содержит только выражения из части SET column = expression команды. Планировщик будет обрабатывать отсутствующие столбцы путем вставки выражений, которые копируют значения из старой строки в новую. Так же, как и для DELETE, добавляется переменная CTID или целая строка, чтобы исполнитель мог идентифицировать старую строку, которую необходимо обновить.

    Каждый элемент в списке назначения содержит выражение, которое может быть постоянным значением, переменной, указывающей на столбец одного из отношений в таблице диапазона, параметром или деревом выражений, состоящим из вызовов функций, констант, переменных, операторов и т.д.

  • квалификация – выражение, очень похожее на одно из тех, которые содержатся в записях целевого списка. Результат этого выражения - логическое значение, которое сообщает о том, следует ли выполнять операцию (INSERT, UPDATE, DELETE, или SELECT) для итоговой строки результата или нет. Это соответствует предложению WHERE оператора SQL.

  • дерево соединений – показывает структуру предложения FROM . Для простого запроса, такого как SELECT ... FROM a, b, c , дерево соединений представляет собой просто список элементов FROM , потому что можно объединять их в любом порядке. Но когда используются выражения JOIN, особенно внешние соединения, приходится соединяться в порядке, показанном соединениями. В этом случае дерево соединений показывает структуру выражений JOIN . Ограничения, связанные с конкретными предложениями JOIN (из выражений ON или USING ), хранятся в виде выражений квалификации, прикрепленных к этим узлам дерева соединений. Оказывается, удобно хранить выражение верхнего уровня WHERE в качестве квалификации, прикрепленной к элементу дерева соединений верхнего уровня. Так что на самом деле дерево соединений представляет оба предложения FROM и WHERE из SELECT .

  • другие – другие части дерева запроса, такие как предложение ORDER BY, здесь не представляют интереса. Система правил заменяет там некоторые записи при применении правил, но это мало связано с основами системы правил.