Как B- и B+-деревья лежат в основе индексов в базах данных (например, InnoDB в MySQL), почему размер и тип первичного ключа (например, BIGINT против UUID) напрямую влияют на глубину дерева, порядок хранения и количество I/O, и как это отражается на скорости поиска и диапазонных запросов

https://planetscale.com/blog/btrees-and-database-indexes

👉 @SQLPortal

Тутор по ограничениям в Postgres — тык

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

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

Ограничения также помогают отлавливать аномальные значения и ситуации, которые вы не предусмотрели в коде приложения, но которые должны быть перехвачены до выполнения INSERT.

👉 @SQLPortal

Мы часто обсуждаем с людьми тему «Почему именно Postgres?». Какие фичи делают его сильнее других баз. В этом списке почти всегда фигурирует индексируемый JSONB.

JSONB в Postgres изначально сделан для эффективных запросов и индексации

Вот отличный материал с обзором этих возможностей.

👉 @SQLPortal

SQL против Python для работы с данными: must-have для аналитиков и дата-сайентистов, которые прокачивают скиллы

👉 @SQLPortal

Используй правильный тип данных при определении колонок в базе данных. Например:

для чисел — numeric, для дат/времени — date или timestamp

Неправильный выбор типа данных приводит к неявным преобразованиям, что может:

- отключить использование индексов → замедлить SQL
- вызвать ошибки во время выполнения

Выбирай типы внимательно.

👉 @SQLPortal

Давай разберём типы сканов в Postgres. Многие из нас уже смотрели планы через EXPLAIN. Ниже — детали по разным видам сканов и схема, которая помогает понять, как они работают.

❖ Sequential Scan
Читает всю таблицу построчно и проверяет каждую строку на соответствие условиям запроса.

❖ Index Scan
Базовый индексный скан использует B-tree, чтобы быстро найти точное место данных. Это двухшаговый процесс: сначала Postgres находит запись в индексе, потом извлекает строку из таблицы.

❖ Bitmap Scan

Bitmap Index Scan. Сначала Postgres сканирует один или несколько индексов и строит в памяти «битмап» — карту страниц таблицы, где возможно находятся нужные строки.

Bitmap Heap Scan. Затем этот битмап используется для прохода по основной таблице. Важный момент — чтение нужных страниц идёт последовательно с диска, что обычно быстрее, чем случайные переходы при стандартном Index Scan.

❖ Parallel Sequential Scan
Postgres запускает несколько background worker’ов, чтобы одновременно сканировать одну большую таблицу. Таблица делится на части, каждая часть достаётся отдельному worker’у. В конце результаты собираются вместе через gather.

❖ Parallel Index Scan
Несколько worker’ов параллельно сканируют разные части одного B-tree индекса и возвращают совпавшие строки из heap. Worker’ы читают индекс по очереди.

❖ Index-Only Scan
Самый быстрый вариант: запрос полностью обслуживается данными, которые есть в индексе. Таблица вообще не трогается.

👉 @SQLPortal

Индексируй базу данных с осторожностью.

Каждый новый индекс приводит к:

(a) увеличению затрат на хранение (и, как следствие, дублированию данных)
(b) увеличению накладных расходов на INSERT

Общий принцип такой: индексы ускоряют чтение, но замедляют запись.

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

Хороший обзор этой темы есть у Маркуса в «Use the Index, Luke.»

👉 @SQLPortal

Для проверки видимости строк Postgres собирает все активные транзакции в массив, а строки сверяет с этим списком. Это становится частью снимка состояния транзакции.

Если строку создала одна из этих транзакций, она не видна.

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

Postgres сортирует этот массив и делает по нему бинарный поиск. Есть патчи, которые при необходимости переносят этот список в хеш-таблицу

👉 @SQLPortal

Вся жизнь перед глазами пронеслась

👉 @SQLPortal

Postgres 18 читает в 2–3 раза быстрее ⚡️

В Postgres 18 появляется крупное изменение в производительности чтения — новая фича async I/O (асинхронный ввод-вывод).

Что такое async I/O?

Когда Postgres читает данные с диска (не из shared buffer), нужен I/O для получения данных.
Синхронный I/O значит, что каждый запрос к диску ждёт завершения, прежде чем делать что-то ещё. Для нагруженных баз, особенно в облаке, это узкое место.

Асинхронный I/O позволяет воркерам использовать простои с пользой.

Запись в Postgres останется синхронной.

Аналогия с async I/O

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

Где async I/O применяется

- последовательные сканы
- bitmap heap scan (после bitmap index scan)
- часть обслуживания, например vacuum

Как включить?

Есть два варианта:

🔸io_method = worker
Shared worker-процессы синхронно загружают данные в shared buffers. Можно задать количество воркеров на инстанс. Поддерживается на всех платформах, где работает Postgres.

🔸io_method = io_uring
Для Postgres на Linux 5.1+ можно использовать системные вызовы io_uring. Тогда обращения выполняются самим backend-процессом, а не отдельными воркерами.

Также появится pg_aios — новый системный view для анализа данных async I/O.

👉 @SQLPortal

Это один из лучших AI-инструментов для разработчиков 🔥

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

Таблицы, поля и связи создаются автоматически, экономя часы на ручной настройке.

Отлично подходит для прототипов и MVP.

Линк: database.build

👉 @SQLPortal