Плохо написанный SQL легко превращается в тормозящий и трудноподдерживаемый кошмар.

Джордан Гудман разобрал типичные анти-паттерны, которых стоит избегать:

- использовать CASE вместо нормальных таблиц,
- вызывать функции на индексированных колонках,
- злоупотреблять DISTINCT, чтобы “починить” дубли.

Подробности — в его статье

👉 @SQLPortal

В копилку полезного: принёс ещё одну огромную базу бесплатных API. Внутри аж 1511 штуки на любой вкус: от игр и погоды до финансов и здоровья

Забираем здесь ✌️

👉 @SQLPortal

SQL тренажеры для практики

- sql-academy.org
- sql-ex.ru
- schoolsw3.com
- SQL Fiddle
- sqltest.online
- Oracle LiveSQL
- stratascratch.com
- stepik.org (Интерактивный тренажер SQL)
- sql-practice.com
- pgexercises.com
- HackerRank
- sqlzoo.net

👉 @SQLPortal

Если увлекаешься технологиями, не пропусти True Tech Champ 21 ноября — масштабный ИТ-фест от МТС 🔥

В программе:

📝 доклады о технологиях будущего от экспертов в ИИ, включая руководителя фундаментальных исследований MWS AI Валентина Малых;
🛻 шоу-битва роботов со спецэффектами и сюжетной линией;
📝 воркшоп по работе с ИИ-агентами от канадского разработчика и автора книги AI Agents in Action Майкла Ланэма, кодинг-практикум с MWS AI и интеллектуальный спарринг с искусственным интеллектом;
◻️ 20+ площадок с активностями: IT-Родео, робофайтинг, лазерный лабиринт и многое другое.
🔴 А в завершение дня — афтепати со звездным хедлайнером.

Фестиваль бесплатный, он пройдет 21 ноября в Москве и онлайн.
Смотри подробную программу на сайте и регистрируйся — количество мест ограничено.

Postgres реализует MVCC с помощью метаданных транзакций на уровне каждой строки.

Каждая строка , которую ты вставляешь в таблицу Postgres, содержит xmin и xmax. xmin - это ID транзакции, создавшей строку, xmax - транзакции, которая обновила или удалила её.

Когда строка обновляется, Postgres не переписывает её на месте. Он создаёт новый tuple с полной копией данных. В старой версии ставит xmax равным ID транзакции, которая сделала апдейт, а в новой - xmin этой же транзакции.

Какую версию строки увидит транзакция, зависит от её собственного ID и уровня изоляции.
Этот механизм позволяет разным транзакциям видеть разные версии данных, что довольно удобно. Но есть и обратная сторона: старые версии строк накапливаются и раздувают таблицу. Чтобы очистить всё это добро, Postgres нужен VACUUM. Со временем приходится прогонять VACUUM (FULL) или использовать утилиты вроде pg_repack, чтобы вернуть место.

👉 @SQLPortal

Логирование медленных запросов в Postgres: ставишь log_min_duration_statement = '2s'

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

Предварительные условия: logging_collector должен быть включён (on), а log_destination настроен на stderr или другой приемник.

👉 @SQLPortal

Новый релиз duckdb получился мощным: завезли поддержку Iceberg для INSERT, UPDATE и DELETE.

duckdb можно встраивать куда угодно, так что его реально запускать прямо внутри Postgres, в Edge Functions, в API-серверах и в прочих местах.

👉 @SQLPortal

Топ причин, почему Postgres не использует индекс:

Его просто нет.

WHERE отбирает больше 5–10% строк. В такой ситуации Postgres выбирает последовательное сканирование, потому что накладные расходы на работу с индексом будут выше.

Планировщик работает со старыми статистиками. Такое бывает после массовой вставки, крупных UPDATE/DELETE, долгого отсутствия VACUUM или при недавно созданных индексах.

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

Несовпадение типа индекса или использование функций над колонками, по которым есть индекс. Например LOWER(email).

Так что если планировщик не использует индекс — почти всегда он делает это потому, что так дешевле по стоимости запроса.

Надеюсь, пригодится.

👉 @SQLPortal

PostgreSQL: самый простой способ извлечения случайных записей

👉 @SQLPortal