JOIN, подзапросы и CTE

Для отчёта нужно сохранить клиентов без подходящих заказов. Определите, как размещение фильтра влияет на результат двух вариантов запроса, и объясните механизм.

WITH clients(id) AS (
    VALUES (1), (2)
), orders(client_id, status) AS (
    VALUES (1, 'paid'), (1, 'cancelled')
)
SELECT 'where' AS variant, c.id, o.status
FROM clients c
LEFT JOIN orders o ON o.client_id = c.id
WHERE o.status = 'paid'
UNION ALL
SELECT 'on', c.id, o.status
FROM clients c
LEFT JOIN orders o
       ON o.client_id = c.id
      AND o.status = 'paid';

Что произойдёт при выполнении скалярного коррелированного подзапроса, если для одной строки внешнего запроса он вернёт несколько строк?

В отчёте одна строка заказа повторяется после соединения с таблицей позиций. Какой механизм определяет число получившихся строк?

Что определяет, будет ли обычный CTE вычислен отдельно или встроен в основной запрос?

Сравните обычное соединение по равенству с null-безопасным сравнением: как обрабатывается пара строк, у которых ключ соединения отсутствует?

В чём различие NOT IN и NOT EXISTS, если подзапрос может вернуть NULL?

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

В иерархии обнаружили циклическую ссылку. Какое поведение следует ожидать от этого рекурсивного CTE?

WITH RECURSIVE edges(child, parent) AS (
    VALUES (1, 2), (2, 1), (3, 2)
), ancestors(node) AS (
    SELECT 3
    UNION ALL
    SELECT e.parent
    FROM edges e
    JOIN ancestors a ON e.child = a.node
)
SELECT node
FROM ancestors;

Что должен сохранить оптимизатор при преобразовании коррелированного EXISTS в полусоединение?

Объясните, почему фильтр по результату оконной функции нельзя безусловно протолкнуть внутрь производной таблицы.

Как область видимости CTE ограничивает использование его имени за пределами оператора, в котором он объявлен?

Можно ли считать сортировку, заданную внутри производной таблицы, гарантией порядка строк внешнего результата?

Почему перестановка INNER JOIN и LEFT JOIN в цепочке может удалить строки, хотя условия соединения не изменились?

Представьте отчёт по клиентам: условие фильтрации заказов можно применить до группировки или после неё. Какой результат следует ожидать при переносе условия через границу агрегации?

Нужно вывести для каждого клиента сумму его заказов. Почему замена коррелированного подзапроса на прямое соединение с таблицей заказов может изменить результат?

В задаче сверки двух источников нужно сохранить строки, найденные только слева, только справа и в обоих источниках. Какой результат вернёт запрос и почему в нём появляются NULL?

WITH left_src(id, value) AS (
    VALUES (1, 'A'), (2, 'B')
), right_src(id, value) AS (
    VALUES (2, 'B2'), (3, 'C')
)
SELECT l.id AS left_id, l.value AS left_value,
       r.id AS right_id, r.value AS right_value
FROM left_src l
FULL OUTER JOIN right_src r ON r.id = l.id;

Какое значение возвращает коррелированный скалярный подзапрос для строки внешнего запроса, если он не находит ни одной строки?

Для рекурсивного CTE как выбор между UNION и UNION ALL влияет на строки, достижимые несколькими путями?

Оптимизатор хочет протолкнуть фильтр внутрь производной таблицы с DISTINCT. Эквивалентны ли исходный и преобразованный запросы, и почему?

WITH rows(id, status) AS (
    VALUES (1, 'paid'), (1, 'cancelled'), (2, 'paid')
)
SELECT id, status
FROM (
    SELECT DISTINCT id, status
    FROM rows
) AS d
WHERE status = 'paid';

SELECT DISTINCT id, status
FROM rows
WHERE status = 'paid';

В запросе выбираются только поля левой таблицы, а правая присоединена через LEFT JOIN. Когда оптимизатор вправе полностью устранить это соединение без изменения результата?