Проверка производительности 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

В SQL можно комбинировать PARTITION BY и ORDER BY в оконных функциях.

Это делит строки на группы по значению PARTITION BY,
а затем считает накопительный итог внутри каждой группы.

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

👉 @SQLPortal