Можно ли при конфликте (INSERT) не обновлять SEQUENCE?

Question

[Ivan Palamarchuk]

Есть таблица, в которой для избежания дубликатов создан столбец count, который обновляется каждый раз, когда пытаешься добавить дубликат, всё это реализовано на основе уникального индекса этих столбцов.

Для добавления/обновления использую синтаксис:

INSERT INTO table (..columns)
VALUES (..columns)
ON CONFLICT (..columns) DO
    UPDATE SET count = table.count + 1

И каждый раз, когда вызывается UPDATE - значение SEQUENCE меняется на n+1
Можно ли как-то на этот процесс повлиять?

Comments

[Сергей Горностаев]

Зачем костыль? Почему бы не сделать before insert trigger?

[Ivan Palamarchuk]

Сергей Горностаев: этот механизм появился в 9.5, а чем before insert лучше? Тестировал, при больших нагрузках всё-таки "проскакивали" записи, которых не было, когда проводился SELECT, а при INSERT они уже были, и тут появлялся конфликт, который как-то нужно было обрабатывать..

[Сергей Горностаев]

Ivan Palamarchuk: триггеры были с очень ранних версий. Лучше они тем, что как раз предназначены для таких задач, как ваша.

[Ivan Palamarchuk]

Сергей Горностаев: если не сложно, можете подсказать, как её реализовать на основе триггеров без "проскоков" записей при большом кол-ве одновременных INSERT'ов?

[Сергей Горностаев]

Ivan Palamarchuk: чтобы проскоков не было, вызывайте INSERT в транзакции.

[Ivan Palamarchuk]

Сергей Горностаев: просто фишка в том, что между SELECT (проверка существования) и INSERT (создание, если нет записей) есть очень маленькое окно времени, при плотном трафике - будут конфликты.

[Ivan Palamarchuk]

Сергей Горностаев: даже если в транзакции это делать

[Сергей Горностаев]

Ivan Palamarchuk: если select и insert в одной транзакции, никакого окна быть не может. Таблица блокируется на изменение для всех до конца транзакции. Под большой нагрузкой это, правда, приведёт к снижению скорости. Но другого выхода просто нет.

Answer 1

[Rsa97]

Такое поведение стандартно для большинства СУБД. Перед началом выполнения INSERT'а запрашивается следующее значение для SERIAL, и СУБД увеличивает счётчик на единицу. Но, поскольку за время выполнения запроса ещё несколько запросов могли потребовать тот же счётчик, то неиспользованные значения обратно не принимаются и образуются пропуски.
Сделать свой счётчик можно, но ценой производительности (www.varlena.com/GeneralBits/130.php). Как правило, смысла в этом нет.