В 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