Два SQL-запроса ниже для планировщика разные:

select * from emp where id = 7

select * from emp where id = 9

Планировщику нужно разобрать скомпилировать и построить план для каждого

Использование bind-переменных позволяет избежать парсинга
Теперь оба хешируются в один и тот же план:

select * from emp where id = ?, 7

select * from emp where id = ?, 9

Из этого вылезают любопытные ситуации:

select * from emp where id between ? and ?, 1, 3

может использовать индекс по id благодаря высокой избирательности, но повторное применение того же индексного плана для

select * from emp where id between ? and ?, 0, 9000000

может быть не таким эффективным как полный скан

Ничего не бывает бесплатным. Всегда есть компромисс

👉 @SQLPortal

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

Заходи на stratascratch.com — там собраны сотни задач с интервью в FAANG и других крупных компаниях

Удобный онлайн-редактор, проверка решений и пояснения помогут прокачать скилл без лишней мороки 🤩

👉 @SQLPortal

Если ты запускаешь транзакцию в уровне изоляции Read Committed (назовём её tx1) и выполняешь долгий SELECT — например, с сортировками и join’ами по большим датасетам — база берёт снимок зафиксированных данных на момент старта этого запроса.

Пока этот SELECT ещё работает, другая транзакция (tx2) в другом сеансе обновляет те же строки и успевает закоммитить.

Несмотря на то что tx2 закоммитила во время выполнения SELECT, твой запрос внутри tx1 этих апдейтов не увидит, потому что каждый запрос в Read Committed использует снимок данных, сделанный в начале его выполнения. Всё, что было зафиксировано после старта запроса, отфильтровывается.

Но если потом в рамках tx1 ты запустишь ещё один SELECT, он уже увидит изменения из tx2, так как возьмёт новый снимок, включающий все коммиты, сделанные к этому моменту.

В Postgres этот снимок строится на основе идентификаторов транзакций.

👉 @SQLPortal

Copilot как функция в Excel

Microsoft только что анонсировала функцию copilot в Excel

Новая функция =COPILOT() в Excel позволяет анализировать данные, генерировать контент и брейнштормить прямо в ячейках таблицы

Подробнее: ссылка

👉 @SQLPortal

Строки, которые возвращают операторов множеств в SQL:

🔸UNION
Все строки из обеих таблиц

🔸MINUS / EXCEPT
Строки из первой таблицы, которых нет во второй

🔸INTERSECT
Строки, которые есть в обеих таблицах одновременно

По умолчанию эти операторы убирают дубликаты.
Клаузa ALL сохраняет и учитывает дубликаты.

👉 @SQLPortal

Проверка производительности Postgres: random_page_cost

Если вы держите базу на SSD, то дефолтные настройки Postgres замедляют вас.

В Postgres есть параметр random_page_cost, который говорит планировщику запросов, насколько дорого читать случайную страницу с диска по сравнению с последовательным чтением.

Планировщик запросов Postgres подбирает наиболее эффективный способ выполнить SQL-запрос. Он делает это, оценивая «стоимость» разных планов выполнения и выбирая тот, у которого общая стоимость ниже.

Представим, что вам нужно найти несколько конкретных товаров в большом супермаркете. Есть два варианта:

- sequential scan
Это как пройтись по каждому ряду магазина подряд от начала до конца. В Postgres это последовательное сканирование. Предсказуемо, между товарами минимум времени.

- index scan
Это как посмотреть в каталог магазина (индекс), найти номер ряда для каждого товара и сразу идти туда. Это индексное сканирование.

random_page_cost отражает цену перехода между разными, несмежными рядами.

🔸Высокий random_page_cost
Это говорит планировщику, что переходы между рядами очень затратные.
В итоге он чаще выберет sequential scan, даже если нужно всего несколько товаров, потому что так он «экономит» на случайных переходах.

🔸Низкий random_page_cost
Это говорит планировщику, что переходы между рядами быстрые.
Тогда он охотнее использует index scan, так как выборочные переходы стоят дешево.

🔸Значения по умолчанию
По умолчанию random_page_cost = 4.0.
Это означает, что случайное чтение страницы считается в 4 раза дороже последовательного.
Это консервативное значение под традиционные HDD.

На SSD или если база целиком помещается в RAM, штраф за случайные чтения намного ниже.
Индексные сканирования быстрее, и «переходы по рядам» дешевле.
Для SSD обычно лучше ставить значение от 1.1 до 1.5.

Последовательное сканирование использует другой параметр seq_page_cost, который по умолчанию равен 1.0.
Но так как итоговые стоимости планов зависят от относительной разницы этих двух параметров, обычно достаточно менять только random_page_cost.

👉 @SQLPortal

Это сайт с ретро‑игровым туториалом, где SQL учишь прямо в браузере, используя DuckDB. Всё интерактивно, весело, и можно сразу пробовать запросы - без установки сервера, без настройки. 🙂

https://dbquacks.com/

👉 @SQLPortal

Клауза ORDER BY в оконных функциях SQL сортирует строки.

Затем функция возвращает накопительный итог в рамках окна

RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW

Это включает все строки, у которых значение сортировки меньше либо равно значению текущей строки.

👉 @SQLPortal

Апдейт Postgres 18: индексируемые UUID

Postgres 18 сейчас в бете и выйдет в продакшен этой осенью.
В uuid добавили поддержку UUIDv7.

UUID — это случайно сгенерированные строки, которые по определению глобально уникальны.

Почему UUID хороши для первичных ключей

1. Уникальность — можно генерировать ключи в разных местах.
2. Развязка — приложение может создать первичный ключ ещё до того, как отправит данные в БД.
3. Безопасность — если в URL используются ID (.../users/5), атакующий легко подберёт другие (.../users/6, .../users/7) и увидит общее количество пользователей.

С UUID (.../users/f47ac10b-58cc-4372-a567-0e02b2c3d479) такое невозможно.

Что изменилось

- Раньше в Postgres нативно поддерживался UUIDv4, но сортировка и индексация в больших таблицах работала медленно.
- UUIDv7 решает проблему сортировки и индексации.

Он по-прежнему случайный, но первые 48 бит (12 символов) — это таймстамп, остальные биты остаются случайными.

Таймстамп

Таймстамп хранится в hex (по сути сжатое десятичное число).

Пример:

0189d6e4a5d6 (hex) = 2707238289622 (decimal),
что соответствует количеству миллисекунд с 1970 года.

Пример DDL для UUIDv7

CREATE TABLE user_actions (
    action_id UUID PRIMARY KEY DEFAULT uuidv7(),
    user_id BIGINT NOT NULL,
    action_description TEXT,
    action_time TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Если раньше у тебя были проблемы с UUID -сейчас можно уже попробовать бету

👉 @SQLPortal