Рассмотрим элементарный пример рекурсивного CTE, возвращающего последовательность целых чисел от 1 до 10.

with recursive nums(iteration) as
( select 1 -- Якорный элемент

  union all
  
  select iteration + 1 --Рекурсивный элемент
  from nums
  where iteration < 10
)
select * from nums
order by iteration

Этот рекурсивный CTE состоит из следующих элементов:

Якорный элемент - в примере это запрос select 1. В общем случае это запрос, который возвращает корректный результат и вызывается всего один раз.

Рекурсивный элемент - в примере это запрос, который идёт после union all. Этот запрос содержит ссылку на имя всего CTE (результирующий набор, полученный на предыдущей итерации) - в примере nums. При первом вызове рекурсивного элемента предшествующий результат представлен значениями, которые вернул закрепленный элемент. При каждом следующем вызове имя CTE представляет результат предыдущего выполнения рекурсивного элемента.

Т.к. между запросами якорного и рекурсивного элемента находится кляуза union all (или union, если по каким-то причинам нужно убрать дубли), очевидно, что оба запроса должны быть совместимы по количеству и типу возвращаемых
столбцов.

Этот пример - генерация числовой последовательности - одно из возможных применений рекурсивного CTE. Но чаще они используются для работы с иерархическими данными.

Итак, поработаем с иерархическими данными на примере известной схемы SCOTT. Выведем номер, имя и должность всех начальников из таблицы scott.emp для выбранного работника на всех уровнях иерархии. Будем искать для empno = 7369. Скрипты создания таблицы и её наполнения можно взять на моём github

with recursive mgr_list (e_level, empno, ename, job, mgr) as (
select 1, a.empno, a.ename, a.job
, a.mgr
from scott.emp a
where a.empno = 7369

union all

select e_level + 1, a.empno, a.ename, a.job
, a.mgr
FROM mgr_list r 
join scott.emp a on r.mgr = a.empno
)

select m.*
, a.ename as mgr_name, a.job as mgr_job 
from mgr_list m
join scott.emp a on m.mgr = a.empno

1. В якорной части конструкции WITH этого запроса выбирается только 1 строка из таблицы для работника с номером 7369 (на скрине выше строка с e_level = 1). Эта строка помещается во временную рабочую таблицу и в результирующую таблицу.

2. Далее в рекурсивной части мы соединяем эту временную рабочую таблицу под алиасом mgr_list с scott.emp. Условие соединения r.mgr = a.empno джойнит строки, в которых позиция работника на следующем уровне иерархии из таблицы scott.emp совпадает с позицией начальника работника на текущем уровне иерархии из датасета mgr_list. На выходе строка с e_level равным 2 на скрине выше доставляется в результирующую таблицу (там уже 2 записи) и во временную таблицу - там только 1 запись.

3. На этом шаге содержимое временной рабочей таблицы заменяется содержимым промежуточной таблицы, а затем промежуточная таблица очищается. После чего аналогично пункту 2 получаем строку с e_level равным 3 на скрине выше. Она доставляется в результирующую таблицу (там уже 3 записи) и в недавно очищенную временную таблицу - там только 1 запись.

4. Повторяем пункты 2 и 3 для работника

Теперь после очистки рабочей таблицы и заполнением её строкой из промежуточной таблицы с данными работника с должностью президент и значением NULL в поле mgr наши итерации заканчиваются (джойн по условию r.mgr = a.empno возвращает пустоту). И все накопленные в результирующей таблице строки доступны внешнему запросу.

Более подробно по теме можно почитать в зачётной книжке PostgreSQL. Профессиональный SQL

Оттуда я взял картинки для иллюстрации пунктов 1 и 3. А ещё там много поучительных задачек, которые можно прорешать и потом преисполниться.

P.S. Кстати, убедиться в том, что в каждую итерацию в рабочую таблицу приходит ровно 1 строка, можно посмотрев план запроса.

FIXME пп 3-4 откорректировать

Существует несколько способов хранения словарей в памяти, каждый из которых имеет свои компромиссы между использованием CPU и RAM (дока Clickhouse). И если - так сложились обстоятельства - ключ словаря это натуральный ключ из источника имеющий строковый тип, а не UInt64, то параметр Layout придётся делать complex_key_hashed.

Посмотрим на примере из пет-проекта. Есть такой источник

Словарь создаётся так

CREATE DICTIONARY portfolio.actual_quotation_dict
(
ticker           String,
quotation        Decimal64(6)
)
PRIMARY KEY ticker
SOURCE(CLICKHOUSE(
	QUERY 'SELECT ticker, quotation FROM portfolio.actual_quotation'
	USER 'username'
	PASSWORD 'password'
	HOST 'localhost'
    PORT 9000
))
LIFETIME(MIN 600 MAX 900)
LAYOUT(complex_key_hashed())

И теперь при использовании словаря вызывая dictGet, нужно обернуть значение из словаря в tuple()

SELECT instr_short, ticker, qty, quotation
,dictGet('portfolio.actual_quotation_dict', 'quotation', tuple(ticker)) as act_quotation
, equity, balance_datetime
FROM portfolio.portfolio_history

Воспользуемся известной схемой SCOTT. Допустим, мы хотим удалить из таблицы emp всех работников из департамента с названием SALES.

По стандарту эту задачу можно решить так:

delete
from scott.emp e
where e.deptno in (select deptno from scott.dept d where d.dname = 'SALES');

Но PostgreSQL при удалении позволяет ссылаться на столбцы других таблиц в условии WHERE, когда эти таблицы перечисляются в предложении USING. Таким образом решение указанной задачи с использованием предложения USING выглядит так:

delete
from scott.emp e
using scott.dept d
where e.deptno = d.deptno and d.dname = 'SALES';

По сути, это дилит с джойном. В MS SQL Server можно было бы в лоб написать join (код ниже), а PostgreSQL пошёл своим путём.

-- вариант удаления в ms sql server через join 
-- (но это не точно, пишу по памяти)
delete e
from scott.emp e
join scott.dept d
  on e.deptno = d.deptno and d.dname = 'SALES';

В документации пишется, что "В ряде случаев запрос в стиле соединения легче написать и он может работать быстрее, чем в стиле вложенного запроса". Так это или нет можно убедиться только на практике.

Кстати, чтобы посмотреть реальный план команды DELETE без фактического её выполнения, можно начать транзакцию, выполнить explain analyze запроса, и потом откатить выполнение командой rollback (рисунок ниже).

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

Также RETURNING может использоваться в командах INSERT, UPDATE и MERGE для получения данных из модифицируемых строк. Подробно об этом можно почитать в документации.

P.S. А ещё кляуза USING может использоваться в ORDER BY. Если верить документации.

Но почему-то в статье документации 7.5. Сортировка строк (ORDER BY) USING уже отсутствует. Может, плохо искал (

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

# multsum([1,5,6]) = 5*6 + 1*6 + 1*5 = 41

# multsum([1,5,6,7]) = 5*6*7 + 1*6*7 + 1*5*7+ 1*5*6 = 317

import math

def multsum(arr: list):
    total_product = math.prod(arr) # Вычисляем общее произведение всех чисел
    sum_of_excluded_products = 0
    
    for num in arr:
        sum_of_excluded_products += total_product // num
            
    return sum_of_excluded_products

Задача: Есть массив целых чисел и число K. Найти два таких (не обязательно различных) числа в массиве, сумма которых равна K, либо вывести, что таких чисел нет.

def find_two_sum(nums, K: int):
    """
    Находит два числа в массиве, сумма которых равна K.
    
    Args:
        nums: Список целых чисел.
        K: Целевая сумма.
        
    Returns:
        Кортеж из двух чисел, если пара найдена, или строка "null", если не найдена.
    """
    
    # Словарь для хранения чисел, которые мы уже встречали
    seen_numbers = {} 
    
    for num in nums:
        # Вычисляем число, которое дополнит текущее `num` до `K`
        complement = K - num
        
        # Если `complement` уже есть в нашем словаре `seen_numbers`,
        # значит, мы нашли нужную пару.
        if complement in seen_numbers:
            return (complement, num)
        
        # Если `complement` не найден, добавляем текущее `num` в словарь,
        # чтобы его могли найти на следующих шагах.
        # Значение в словаре (например, True или индекс) не имеет значения для этой конкретной задачи,
        # главное, чтобы ключ был добавлен.
        seen_numbers[num] = True 
        
    # Если цикл завершился, и мы не нашли пару, возвращаем "null"
    return "null"

Задача: Дана строка из латинских заглавных букв. Необходимо заменить все повторы одинаковых подряд идущих букв на букву + цифру. Одиночные буквы заменять не надо.

def compress_rle(s: str) -> str:
    """
    Сжимает строку: для подряд идущих одинаковых символов длины >= 2
    заменяет их на 'символ' + 'число'. Одиночные символы не меняет.
    Пример: "AAAABBB CAAA" -> "A4B3C A3" (пробелы сохраняются)
    """
    if not s:
        return ""
    
    res = []
    prev = s[0]
    count = 1
    
    for ch in s[1:]:
        if ch == prev:
            count += 1
        else:
            # Завершили блок
            if count == 1:
                res.append(prev)
            else:
                res.append(f"{prev}{count}")
            prev = ch
            count = 1
    
    # Добавляем последний блок
    if count == 1:
        res.append(prev)
    else:
        res.append(f"{prev}{count}")
    
    return "".join(res)

Задача о «Правильной скобочной последовательности» (Valid Parentheses)

Дана строка, состоящая только из символов скобок: '(', ')', '{', '}', '[' и ']'.
Определите, является ли входная строка валидной.
Строка считается валидной, если:

1. Открытые скобки должны быть закрыты скобками того же типа.

2. Открытые скобки должны быть закрыты в правильном порядке.

3. Каждая закрывающая скобка должна иметь соответствующую ей открывающую скобку того же типа.
Примеры:

• Вход: s = "()" — Вывод: True
• Вход: s = "()[]{}" — Вывод: True
• Вход: s = "(]" — Вывод: False
• Вход: s = "([)]" — Вывод: False
• Вход: s = "{[]}" — Вывод: True

def is_valid(s: str) -> bool:
    # Словарь соответствия закрывающей скобки открывающей
    bracket_map = {
        ")": "(",
        "}": "{",
        "]": "["
    }
    
    # Стек для хранения открывающих скобок
    stack = []
    
    for char in s:
        # Если символ — это закрывающая скобка
        if char in bracket_map:
            # Извлекаем верхний элемент из стека, если он не пуст,
            # иначе присваиваем заглушку (например, '#')
            top_element = stack.pop() if stack else '#'
            
            # Если открывающая скобка из стека не совпадает с нужной для этого типа
            if bracket_map[char] != top_element:
                return False
        else:
            # Если символ — открывающая скобка, кладем её в стек
            stack.append(char)
            
    # Если в конце стек пуст — все скобки закрыты корректно
    return not stack

В предыдущей заметке мы рассмотрели вариант реализации пайплайна по сбору Data Vault и его первичного заполнения. Но случай с изменением данных в источнике и его обработка в сателлите не был рассмотрен.

Будем тренироваться на таблице актеров, изменим актерам с ид 1 и 2 имена. До изменения они выглядят так.

Пускай с сегодняшнего дня актёр с именем PENELOPE станет OLEG, а NICK - Petr. Сказано - сделано.

update sakila.actor set first_name = 
  case actor_id when 1 then 'OLEG' else 'Petr' end
where actor_id in (1,2)

Смотрим изменения

Выполняем трансформацию sat_actor, у нас должно появиться 2 новые записи в таблице сателлита и 2 старые записи должны закрыться текущей датой. Проверяем.

select * 
from sakila_data_vault.sat_actor
where hub_actor_id in (1,2)

На рисунке видно, что трансформация отработала корректно. SCD2 присутствует.

P.S. Если посмотреть код забора данных источника в трансформации, то видно, что каждый раз берутся все данные.

В реальности, конечно, мы бы не стали при последующих запусках тащить все данные источника, а использовали бы в запросе условие-привязку к дате обновления на источнике.

from actor
where last_update > 
/* тут возможно будет дата предыдущего запуска трансформации
 чтобы взять только инкремент */
order by 1

Итак, глава 19 Data Vault Management.

Источником является учебная БД Sakila, MySQL. В книге она описывается, но можно и тут про неё прочитать https://dev.mysql.com/doc/sakila/en/.

Почему-то репозиторий с файлами книги у меня на раз не нагуглился, поэтому выложил примеры к 19 главе на свой гитхаб. Все файлы джобов и трансформаций можно взять здесь

Там же находится файл sakila_data_vault_schema.sql с DDL формирующим таблицы хабов, линков и сателлитов.

Основная проблема, на которую я наткнулся при воспроизведении ETL из книги, это незаполненный степ Filter rows в трансформациях по сбору сателлитов (на картинке ниже)

Я в паре трансформаций этот баг исправил, и сбор этих сателлитов завёлся.

И, к сожалению, авторы не приложили sql-код для эмуляции изменений данных на источнике. Т.е. доступно только первичное наполнение данных, без инкремента. Так что для проверки корректности ведения SCD2 это тоже нужно будет делать самому.

После построения хоронилища по Data Vault предлагается натянуть на него star schema. Джобы и трансформации прилагаются, но их работоспособность и корректность я уже не проверял.

И, кстати, странно, что не был создан финальный джоб, запускающий наполнение Data Vault целиком. Что-то вроде такого

В общем и целом для "потрогать" data vault приемлемый вариант.

Заметка будет дополняться со временем.

1)Имеется таблица курсов валют следующей структуры:

create table scott.rates(
curr_id int, — ид валюты
date_rate DATE, — дата курса
rate numeric)

Курс валюты устанавливается не на каждую календарную дату и действует до следующей смены курса

Уникальный ключ: curr_id + date_rate.

Напишите запрос, который покажет действующее значение курса заданной валюты на любую заданную календарную дату.

Требуемый результат:

Для валюты 1 на 03.01.2010 получить курс 32

Для валюты 2 на 10.01.2010 получить курс 41

Решение через оконные функции самое универсальное, хотя в PostgreSQL можно решить через distinct on - см заметку (а в Oracle через keep (dense_rank ...)).

Решение:

with prep as (
select * 
,row_number() over (partition by curr_id order by date_rate desc) rn
from scott.rates
where true
and curr_id = 1
and date_rate <= '2010-01-03'
)
select * from prep where rn = 1

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

2)Посчитайте по таблице FactSales скользящее среднее по продажам (поле SalesAmount) за окно в 3 дня (время в поле OrderDate) в разрезе StoreId, ProductId.

FactSales
OrderDate
StoreId
ProductId
SalesAmount

Решение:

Select f.*
, avg(FactSales) over(partition by StoreId, ProductId 
order by OrderDate rows between 2 preceding and current row) running_avg
From FactSales f

3)Дана таблица валют (справочник), необходимо написать запрос, который возвращает отсортированный список валют в алфавитном порядке по столбцу ISO_CODE, причем первыми должны идти основные валюты, с которыми работает банк: RUR, USD, EUR.

create table scott.currency_dict (iso_code text, iso_name text);

Решение:

select
iso_code,
iso_name
from scott.currency_dict
order by 
  case iso_code when  'RUR'then 1 when 'USD' then 2 when 'EUR' then 3 end
  , iso_code

4)Необходимо получить в результате запроса только актуальные данные по каждой товарной позиции и дате начала действия ее цены
из этих данных построить периоды действия где дата окончания действия текущей цены является датой начала действия следующей -1 день

create table scott.scd2 (  
article     int,     --id товарной позиции
price       numeric,   --цена
date_from   date,    --дата начала действия цены
date_change date    --техническое поле даты изменения версии строки SCD2
)

Честно признаться, ни на собесе, ни сейчас не понял, что нужно сделать. Мутное ТЗ. Нужно уточнять, пока такой вариант решения.

with base as (
select
    article,
    price,
    date_from,
    row_number() over (partition by article, date_from order by date_change desc) as rn
from scott.scd2

)
select
    article,
    price,
    date_from,
    lead(date_from, 1, '4000-01-01'::date) over (partition by article order by date_from) as date_to
from base
where rn = 1

5) Вариация на тему задачи 1

Напишите sql запрос, который будет переводить сумму транзакций из rub в usd (ccy_code = 840) с учетом того, что в таблице rates данные только за рабочие дни. Транзакции, совершенные в выходные, пересчитываются по курсу последнего рабочего дня перед праздником/выходным. Результат: Клиент, дата, сумма операций в usd.

Решение:

select client_id, t.report_date, txn_amount/r.ccy_rate amount_usd
from dbo.transactions t
left join lateral
(select * from dbo.rates r 
where r.ccy_code  = '840' 
and r.report_date <= t.report_date 
order by r.report_date desc limit 1) r 
  on true

Это, кстати, частый обоснованный пример использования lateral join - получение TOP N значений в внешнем запросе. В том же MS SQL Server 2005 такое ещё 10+ лет назад приходилось делать, но используя кляузу outer apply вместо lateral join. В оракеле с 12 версии тоже так можно делать.

6)

В таблице oper_data содержится информация по транзакциям клиентов в офисах физической сети. txn_type принимает значения debit, credit

Напишите sql запрос, который для каждого клиента выводит сумму debit, credit операций и последний посещенный офис по месяцам. Результат представьте в виде:

Решение:

select client_id, report_date
,sum (case when txn_type = 'debit' then txn_amount else 0 end) over (partition by client_id, date_part('month', report_date)) debit_amount
,sum (case when txn_type = 'credit' then txn_amount else 0 end) over (partition by client_id, date_part('month', report_date)) credit_amount
,last_value (office_number) over (partition by client_id, date_part('month', report_date) 
  order by report_date  rows between unbounded preceding and unbounded following) last_office
from dbo.oper_data

Тут вместо староверного подсчёта суммы через case (я - старовер) можно использовать кляузу filter. Ну и помнить про такие оконки, как first value/last value. Я их в проде ни разу не использовал. ¯\_(ツ)_/¯
Можно обойтись без last_value, если вынести расчёт последнего посещенного офиса в разрезе клиента и месяца в CTE, а потом зажойнить с расчитанными дебетовыми и кредитовыми оборотами.

Это такая не редкая задача на собесах - показать, что ты владеешь магией написать sum (case when ... Иногда даже достаточно это проговорить, что ты знаком с этой магией)).

7)Задачка на знания (или воспоминания) о рекурсивных CTE - уже и такое могут на собесе навалить. Взял в канале https://t.me/data_penguin

Для каждого сотрудника вывести его имя, уровень в иерархии (0 для топ-менеджера). Отсортировать по уровню, затем по имени.

Решение:

with recursive mgr_list (e_level, empno, ename, job, mgr) as (
select 0
, a.empno
, a.ename
, a.job
, a.mgr
from scott.emp a
where a.empno = 7839 --президент, у него нет начальника
union all
select e_level + 1, a.empno, a.ename, a.job, a.mgr
FROM mgr_list r 
join scott.emp a on a.mgr = r.empno
)
--вывожу больше полей, чем в ТЗ - для наглядности
select m.*
from mgr_list m
order by e_level, ename

P.S. На недавнем собесе в Яндекс такая финальная задачка была: запрос работает год, и внезапно стал работать в 2 (может быть другое число) раза медленнее. Что бы ты предпринял?

Я весь сиквельный код пишу в лоу-кейсе, если иное не вменяется код-стайлом.

Хорошую цитату нашёл сегодня, читая книжку. Она про то, что писать в аппер-кейсе - не стильно))

Uppercase keywords are associated with older programming languages, such as
assembly, Fortran, and COBOL. SQL is an old language, which has some advantages, but there are negative connotations with our code looking ancient. Decades ago, there were good technical reasons to use upper case, but those reasons no longer apply.
The cultural convention today is to use lower case for programming. And lower case, or mixed case, is obviously the typical choice for normal writing. (There is a consensus that it is easier to read lowercase writing than uppercase writing. But it’s debatable why lower case is easier to read, and I’m not sure if the research applies to monospaced fonts used in programming languages.)
But there are certainly still times when upper case is helpful. When embedding small SQL statements inside other languages, it helps to use upper case to contrast the SQL with the other language. Upper case is also useful when writing emails or posts. And upper case can be useful for helping parts of our PL/SQL programs stick out, like for global constants.
Most of our time looking at code is in an IDE, where the syntax highlighting is more
important than using case for identifying keywords. There aren’t huge advantages to using lower case, but if it looks better, is more readable, and is easier to type, we might as well abandon upper case.

Перед тем, как смотреть план запроса, стоит посмотреть на сам запрос. Возможно, в глаза сразу бросится код, который выглядит подозрительно неоптимальным. Например, бывает, что остаются отладочные артефакты в коде, типа сортировки в подзапросах (order by). Или ошибочный union вместо union all. Или distinct по большому количеству полей. Соединения таблиц по условию неравенства или OR на ключи join. Проход таблицы более 1 раза на ровном месте (мне такие запросы аналитики регулярно подкидывают, причём разные люди, как по шаблону пишут). И тд и тп.

На что обратить внимание в плане запроса:

• Узлы с наибольшей добавочной стоимостью
• Узлы с наибольшим временем выполнения (при explain analyze)
• Большое количество возвращаемых строк на сегмент
• Nested Loop join при большом количестве строк
• Hash join при небольшом количестве строк
• Отсутствие Partition Selector при обращении к партиционированной таблице
• Операторы Redistribute Motion, Broadcast Motion (Появление Redistribute или Broadcast Motion перед операторами соединения значит, что ключ распределения таблицы не совпадает с ключом join. Иногда это говорит о неоптимальной физической модели данных). Оператор Gather Motion, появившийся в середине плана (Это значит, что данные со всех сегментов обрабатываются на мастере, который значительно уступает по производительности множеству сегментов кластера.
  В норме Gather Motion появляется только в самом конце запроса (наверху плана) для вывода результатов запроса через мастер клиенту).
• Наличие факта создания спилл-файлов (в выводе команды EXPLAIN ANALYZE один или несколько слайсов запроса отмечены звёздочкой, например * (slice1))
• rows=1 в операторах Seq Scan, Dynamic Seq Scan, Index Scan и Bitmap Heap Scan
• Несколько Seq Scan одной таблицы (Seq Scan on my_table ... Seq Scan on my_table my_table_1 и тп)

Планировщик может построить неоптимальное дерево плана запроса по разным причинам:

• Отсутствующая или неактуальная статистика, из-за которой планировщик неверно оценивает стоимость плана.
• Неоптимальная физическая модель данных, из-за которой планировщику приходится добавлять тяжёлые операторы Redistribute / Broadcast Motion и неэффективно читать данные из таблиц.
• Сам SQL-запрос, в котором логика получения результата может быть слишком сложной: планировщик не может упростить логику самостоятельно и выбирает среди заведомо неоптимальных вариантов.

Как можно ускорить тяжёлый запрос? Или переписать сам запрос, или оптимизация окружения выполнения запроса. Или и то, и то.

По рефакторингу запроса это скорее магия, чем последовательность чётких инструкций. А по второму варианту - это актуализация статистики, изменение физической модели и, возможно, изменение типа планировщика.

В Гринплуне существует 2 оптимизатора - легаси и GPORCA. Предания гласят, что в большинстве случаев GPORCA справляется лучше. Поэтому стоит знать, что если в коде используются чисто постгресовские кляузы типа distinct on, то будет использоваться не GPORCA, а легаси оптимизатор.

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

P.S. Автор ТГ-канала Инженерообязанный на ютубе выложил вполне годное видео по сабжу Простая оптимизация запросов в GreenPlum + кейсы

Если в хуке выполняется единственный запрос, текст запроса оформляется в кавычки (см пример такого конфига модели ниже)

{{ config
(materialized='table',
alias='emp',
schema='ods_scott',
tags=['ods_layer'],
pre_hook="
insert into scott.model_run_log (log_text, log_dt) 
values ('{{this.schema}}.{{this.table}} start' , now())
"
)
}}

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

Пример вызова нескольких команд DDL в прехуке:

pre_hook=["truncate table t1;", "truncate table t2;","truncate table t3;"]

Пример вызова макроса в прехуке:

pre_hook = ["{{truncate_table()}}"]

Для реляционных СУБД хуки выполняются в той же транзакции, что и выполнение базового ресурса (модели и тд).

Чтобы изменить такое поведение и реализовать что-то навроде автономных транзакций, можно использовать в блоке конфигурации ресурса вспомогательные макросы before_begin и after_commit.

На рисунке ниже модель не будет собрана, но sql-statement из прехука (запись в таблицу аудита) выполнен будет.

IRL в прехуке видел только truncate таблицы в инкрементальных моделях. В постхуках мне пока ничего кроме команды analyze не встречалось.

P.S. Напоминаю, что одиночный sql-statement, не возвращающий dataset, также можно выполнить с использованием функции run_query(), например:

{%do run_query ('truncate table scott.model_run_log')%}