В Postgres можно делать функциональные индексы для запросов, которые приходят в конкретном формате. Например, для TIMESTAMP, когда в запросе фильтрация идет только по дате:

CREATE INDEX idx_orders_dt_only ON orders ((created_at::date)); 

SELECT count(*) FROM orders WHERE created_at::date = '2024-05-20';

👉 @SQLPortal

В 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

😒 Подборка каналов по информационной безопасности

Проверенные каналы по безопасности, которые реально помогают расти.

👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля
👍 Белый Хакер — Свежие новости из мира ИБ
😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг
👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям

📂 Подписывайся

Полезные 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