Использование единого генератора последовательностей в PostgreSQL - плохая идея?

Question

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

Я обрисовал производительность и узкое место, потому что прекрасно знаю, что последовательности PostgreSQL безопасны, как объясняется в другом месте и в PostgreSQL: используется ли потокобезопасный генератор SELECT nextval в суровых многопользовательских средах?. Кроме того, я не возражаю против дырок, которые может образовать последовательность.

У меня есть несколько таблиц (< 60), каждая со своим суррогатным первичным ключом id, объявленный как

id int generated by default as identity

Большинство таблиц, содержащих общедоступные объекты, подробно описываются подмножеством общих общих таблиц. Например, таблицы какproduct, category, post или user детализированы таблицей text, который содержит все varchars общедоступного объекта для разных языков в приложении.

Как id столбцы всех этих публичных объектов могут иметь одно и то же значение, я должен использовать пару

object_id    int not null,
object_type  tobject not null,

однозначно ссылаться text государственным учреждениям это подробности.

Понятно, чем иметь id столбцы с уникальными значениями, происходящими из одной последовательности, позволили бы мне удалить object_typeстолбцы из всех общих таблиц и кода SQL приложения. Это также упростит (и, надеюсь, ускорит) индексацию общих таблиц.

Поскольку я планирую увеличить количество общих таблиц, мой вопрос заключается в том, как генераторы последовательностей работают с параллелизмом при высокой записи. Будет ли генератор одиночной последовательности узким местом при одновременном использовании множестваinsert into попытаться выпустить nextval? Не лучше ли оставить по одному на стол?

Answer 1

Не комментируя в своем дизайне, единичная последовательность не будет проблемой.

Последовательности оптимизированы для параллелизма, и если nextval на самом деле может стать узким местом, вы можете изменить последовательность, чтобы использовать CACHE n за n > 1. Тогда каждый вызов последовательности фактически получает следующийn значения, которые кэшируются сеансом базы данных.

Обязательно используйте bigint, бот integer как тип данных, так что вы не можете исчерпать значения последовательности.