В Postgres 18 появился новый метод клонирования для создания баз данных из шаблонных (template) БД, который работает заметно быстрее, чем другие способы. Это работает на конкретных файловых системах, которые поддерживают copy-on-write / reflink.


👉 @SQLPortal

Какой SQL-запрос работает быстрее?

SELECT * FROM orders
WHERE status = 'NEW'
   OR status = 'PENDING'
   OR status = 'PROCESSING';

vs

SELECT * FROM orders
WHERE status IN ('NEW', 'PENDING', 'PROCESSING');

👉 @SQLPortal

Перестань переписывать JOIN через ON; используй USING

Если ты давно пишешь JOIN’ы в SQL, ты наверняка привык к ON. Оно работает и делает свою работу. Но когда ты джоинишь две таблицы по колонкам с абсолютно одинаковым именем, есть более чистый и аккуратный вариант: USING.

Вот почему стоит подумать о переходе.

SELECT 
       e.Employee_ID,
       e.Employee_Name, 
       e.Department, 
       s.Net_Sales
FROM Employees e 
JOIN sales s
ON e.Employee_ID = s.Employee_ID;

ON ок, но оно многословное. Приходится повторять и имена таблиц, и имена колонок. Если имя колонки одинаковое в обеих таблицах, ты по сути пишешь одно и то же дважды. Хуже того: когда выбираешь колонки, можешь получить два столбца Employee_ID, если явно не квалифицировать их.

USING это сокращение для join’ов по равенству, когда колонки называются одинаково. Та же самая выборка будет такой:

SELECT 
     e.Employee_ID,
     e.Employee_Name, 
     e.Department, 
     s.Net_Sales
FROM Employees e 
JOIN sales s
USING (Employee_ID);

Намного чище, да? USING автоматически сопоставляет колонки с одинаковым именем и делает inner join (или left/right join, в зависимости от типа join). Ты указываешь имя колонки один раз.

Перейти на USING это маленькое изменение, которое делает SQL короче и более “самодокументируемым”. Меньше шансов ошибиться, и результирующий набор получается аккуратнее. В следующий раз, когда джоинишь по одинаково названным колонкам, выкинь ON и попробуй USING. Только проверь, что твоя СУБД поддерживает USING.

👉 @SQLPortal

В Postgres есть unlogged-таблицы: для них отключается Write-Ahead Logging (WAL). За счёт этого запись становится заметно быстрее, но очевидная цена — такие таблицы не реплицируются через WAL и после крэша/перезапуска их содержимое не восстанавливается (по сути, данные считаются временными). В некоторых сценариях этот размен реально оправдан.

👉 @SQLPortal

Как выполнить поиск по нескольким условиям с помощью Xlookup

👉 @SQLPortal

JSONB-колонки Postgres и TOAST: гайд по производительности

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

Работа с API и массивами в типе jsonb в последнее время стала заметно популярнее, и хранить куски данных приложения в jsonb превратилось в распространённый паттерн.

Но зачем вообще “нарезать” JSON-объект на строки и колонки, а потом собирать его обратно, чтобы отправить клиенту?

Ответ: эффективность. Postgres быстрее всего работает со строками и колонками, а когда ты прячешь структуру данных внутрь JSON, движку сложнее разогнаться на максимум, как он мог бы.

👉 @SQLPortal

Полезные Excel формулы

👉 @SQLPortal

Краткая шпаргалка по SQL с примерами запросов

https://github.com/enochtangg/quick-SQL-cheatsheet

👉 @SQLPortal

Cтатья про ACID-свойства.

Не только теория, но и практическая реализация на PostgreSQL с примерами из реальной жизни.

Этот пост отлично зайдет новичкам, которые хотят начать разбираться в базах данных, и он же нужен как база перед моей серией про внутренности PostgreSQL.

👉 @SQLPortal

😢😢😢

👉 @SQLPortal

Поток данных в Postgres для чтения/записи:

Приложение --> (опционально) пулер --> отдельный backend/клиентское соединение --> shared buffers --> кэш ОС (page cache) --> физический диск.

При чтении к кэшу ОС или диску обращается только если нужных страниц нет в shared buffers.

👉 @SQLPortal

Open-source инструмент Text2SQL, который превращает запросы на естественном языке в SQL, используя понимание схемы на базе графа. Задавай вопросы к базе простым языком, а QueryWeaver сам сделает всю склейку и соберет нужный SQL.

https://github.com/FalkorDB/QueryWeaver

👉 @SQLPortal

Не используй CASE в WHERE

Один из самых частых SQL анти-паттернов это пихать CASE прямо в WHERE, чтобы разрулить условную логику для диапазонов или фильтров.

Классический пример:

SELECT * FROM products
WHERE 
  CASE WHEN category = 'Electronics' THEN price < 500 ELSE price < 100 END;

Работает, но часто убивает производительность, потому что CASE делает предикат не SARGable в большинстве популярных СУБД. Оптимизатор уже не может нормально сделать index seek по индексу на price (или по составному индексу (category, price)). В итоге нередко получаешь full table scan, даже если индексы отличные.

Лучше переписать так:

SELECT * FROM products
WHERE price < 100
   OR (category = 'Electronics' AND price < 500);

Этот вариант лучше, потому что логика становится прямолинейной и без лишних условий. Запрос проще читать, проще поддерживать, и оптимизатору проще рассуждать о предикатах, потому что они “голые”, без обертки в логическое ветвление.

👉 @SQLPortal

Вопрос по SQL

Нужно получить:

- все товары дешевле 100
- плюс товары из категории Electronics дешевле 500

Какое условие корректно вернет такой результат?

A)

price < 100 AND category = 'Electronics' OR price < 500

B)

price < 100 OR (category = 'Electronics' AND price < 500)

C)

(price < 100 OR category = 'Electronics') AND price < 500

👉 @SQLPortal

Если используешь COUNT вместе с CASE, не ставь ELSE 0

Пример:

SELECT 
  Department,
  COUNT(CASE WHEN Status = 'Active' THEN EmployeeID ELSE 0 END) AS ActiveCount
FROM Employees
GROUP BY Department;

Это неправильно и даст некорректный результат. Когда ты пишешь ELSE 0, COUNT начинает считать нули как значения. COUNT игнорирует только NULL, а ноль это не NULL. Поэтому если в отделе 10 активных и 5 неактивных сотрудников, запрос вернет 15 для ActiveCount, потому что посчитает все 15 строк (10 EmployeeID + 5 нулей).

Лучше так: убрать ELSE 0:

SELECT 
  Department,
  COUNT(CASE WHEN Status = 'Active' THEN EmployeeID END) AS ActiveCount
FROM Employees
GROUP BY Department;

ELSE тут не нужен. Если условие не выполняется, выражение вернет NULL, а COUNT NULL-ы не считает. Еще более явно можно написать так:

SELECT 
  Department,
  COUNT(CASE WHEN Status = 'Active' THEN 1 END) AS ActiveCount
FROM Employees
GROUP BY Department;

Единственный случай, когда ELSE 0 будет уместен, это если вместо COUNT ты используешь SUM.

👉 @SQLPortal

Какие отношения существуют между этими тремя таблицами и как вы это узнаете?

👉 @SQLPortal

Использование SKIP LOCKED в Postgres в запросах или процессах позволяет строить очереди задач, гарантируя, что отдельные строки обрабатываются внутри транзакции без блокировки при одновременной работе нескольких экземпляров джобы.

👉 @SQLPortal