🤔 PostgreSQL — разбор методов оптимизации!

Статья о том, как анализировать производительность PostgreSQL, находить причины медленных запросов и устранять узкие места. Материал помогает разобраться, какие факторы влияют на скорость обработки данных и как подходить к оптимизации системно. Основное внимание уделяется индексам, планам выполнения SQL-запросов, инструменту EXPLAIN ANALYZE и настройке PostgreSQL.

📌 Оставляю ссылочку: senzpo.ru

➡️ SQL Ready | #сайт

Как использовать SKIP LOCKED для параллельной обработки задач в postgresql!

При реализации очереди задач на postgresql несколько воркеров могут одновременно выбирать задания из одной таблицы. SELECT ... FOR UPDATE блокирует выбранные строки, но остальные воркеры могут ожидать освобождения тех же блокировок.

Для таких случаев postgresql поддерживает FOR UPDATE SKIP LOCKED, позволяющий пропускать строки, уже заблокированные другими транзакциями. Рассмотрим таблицу очереди:

CREATE TABLE jobs (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    status TEXT NOT NULL DEFAULT 'pending',
    payload JSONB NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Для атомарного получения и резервирования одной задачи можно объединить выборку и обновление через UPDATE ... FROM:

WITH next_job AS (
    SELECT id
    FROM jobs
    WHERE status = 'pending'
    ORDER BY created_at, id
    FOR UPDATE SKIP LOCKED
    LIMIT 1
)
UPDATE jobs j
SET status = 'processing'
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.payload;

Подзапрос выбирает доступную задачу и блокирует её строку. Если другой воркер уже удерживает блокировку, SKIP LOCKED позволяет перейти к следующей подходящей записи без ожидания этой блокировки.

UPDATE изменяет статус в той же транзакции, а RETURNING возвращает данные зарезервированной задачи. Для ускорения поиска доступных заданий можно использовать частичный индекс:

CREATE INDEX idx_jobs_pending
ON jobs (created_at, id)
WHERE status = 'pending';

Индекс ускоряет поиск задач со статусом pending. При этом SKIP LOCKED не гарантирует строгий FIFO: заблокированные строки пропускаются.

После резервирования необходимо завершить транзакцию (COMMIT), а обработку выполнять отдельно. При использовании autocommit транзакция завершается автоматически.

Если воркер упадёт, задача может остаться в статусе processing. Поэтому обычно используют аренду задач (locked_until) и механизм повторного получения после её истечения. SKIP LOCKED пропускает заблокированные строки, но не исключает ожидание табличных блокировок.

🔥 FOR UPDATE SKIP LOCKED позволяет нескольким воркерам конкурентно резервировать задачи без ожидания заблокированных строк. В сочетании с UPDATE ... RETURNING и частичным индексом это основа очереди на postgresql, но для надёжной обработки необходим механизм восстановления зависших задач.

➡️ SQL Ready | #практика

😎 Интересная статья попалась на Хабре: «Qwen3.8 27B обошла GPT-5.6 в SQL‑бенчмарке. И всё это — локально на ноутбуке»!

В этой статье:
• Узнаете, как локальная Qwen3.8 27B показала результаты выше GPT-5.6 в SQL-бенчмарке DABstep;
• Разберётесь, как запустить модель на ноутбуке с помощью LM Studio и DuckDB для анализа данных;
• Сравните точность, скорость и стоимость локальных и облачных LLM, а также влияние квантования на производительность.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Почему SELECT перед INSERT не защищает от дубликатов!

Рассмотрим пример на PostgreSQL: две транзакции одновременно пытаются создать пользователя с одинаковым email. Сначала создадим таблицу с ограничением UNIQUE:

CREATE TABLE users (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email TEXT NOT NULL UNIQUE
);

Перед добавлением пользователя приложение проверяет, существует ли такой email:

SELECT id
FROM users
WHERE email = 'admin@example.com';

Если запись не найдена, выполняется вставка:

INSERT INTO users (email)
VALUES ('admin@example.com');

При параллельных запросах обе транзакции могут не найти запись. Первая выполнит INSERT и COMMIT, а вторая получит ошибку нарушения UNIQUE. Это типичная race condition (check-then-act). Без ограничения UNIQUE возникли бы дубликаты.

В PostgreSQL такую ситуацию можно обработать через ON CONFLICT без предварительного SELECT:

INSERT INTO users (email)
VALUES ('admin@example.com')
ON CONFLICT (email) DO NOTHING
RETURNING id;

Если запись создана, RETURNING вернёт её id. При конфликте вставка пропускается, а результат будет пустым. Если существующую запись необходимо обновить, используется DO UPDATE:

INSERT INTO users (email)
VALUES ('admin@example.com')
ON CONFLICT (email)
DO UPDATE SET email = EXCLUDED.email
RETURNING id;

Но обновлять email тем же значением только ради получения id не стоит: операция UPDATE может создавать новую версию строки, запускать триггеры и увеличивать нагрузку.

Если нужен id существующей записи без обновления, после DO NOTHING можно выполнить отдельный SELECT, учитывая уровень изоляции и возможность повторной попытки.

🔥 SELECT перед INSERT не гарантирует уникальность при конкурентном доступе. Её обеспечивает ограничение UNIQUE, а ON CONFLICT позволяет корректно обрабатывать конфликты без предварительной проверки.

➡️ SQL Ready | #практика

Ищите данные внутри JSON без разворачивания массивов!

Когда нужно отфильтровать элементы массива внутри JSON, обычно используют jsonb_array_elements(), дополнительные соединения и условия WHERE.

Но PostgreSQL поддерживает JSONPath — язык запросов к JSON, который позволяет описать фильтрацию прямо внутри пути.

Например, получить названия товаров дороже 1000:

SELECT jsonb_path_query_array(
payload,
'$.items[*] ? (@.price > 1000).name'
)
FROM orders;

Здесь [*] перебирает элементы массива, ? (...) фильтрует их, а .name извлекает нужное поле. Результат возвращается одним JSON-массивом.

Можно использовать JSONPath и непосредственно в WHERE:

SELECT id
FROM orders
WHERE payload @? '$.items[*] ? (@.price > 1000)';

Оператор @? проверяет, существует ли элемент, соответствующий указанному пути. Для подходящих запросов по jsonb PostgreSQL также может использовать индекс GIN.

🔥 JSONPath позволяет фильтровать вложенные JSON-массивы прямо в выражении, без разворачивания элементов и дополнительных соединений.

➡️ SQL Ready | #совет

📂 Шпаргалка по AWS RDS — управление SQL-базами данных!

Amazon RDS — управляемый сервис AWS, который упрощает развёртывание, администрирование и масштабирование реляционных баз данных.

На картинке — 6 основных этапов работы с RDS: от создания и настройки БД до резервного копирования, мониторинга и обеспечения отказоустойчивости.

Шпаргалка поможет быстро вспомнить основные возможности сервиса и разобраться, какие задачи AWS автоматизирует. Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс