У нас данные "временных" таблиц используются только в пределах транзакции, поэтому выбрали такое же решение с unlogged table. Поскольку данные используются только в пределах транзакции, то каждая транзакция видит только данные, которые она сама и создала.
Использование deferred constraint trigger гарантирует, что блокировка строки в mytable_count будет максимально короткой
Это верно, но для TRUNCATE mytable триггер выполняется немедленно, и это может быть проблемой. Рассмотрим такой пример:
транзакция 1: begin; TRUNCATE mytable;…… commit; --начинается раньше, но долгая
транзакция 2: begin; Insert into mytable; commit; — позже и короткая
Но транзакции 2 придётся ожидать окончания транзакции 1, поскольку транзакция 1 заблокировала таблицу mytable_count
И надо учитывать, что deferred constraint trigger может привести к такой проблеме:
в транзакции сначала вставили\удалили строки в mytable, а позже есть логика, завязанная на количество записей в mytable, и берём мы его из mytable_count, но в mytable_count не учтены вставили\удаления, выполненные в этой транзакции
У нас данные "временных" таблиц используются только в пределах транзакции, поэтому выбрали такое же решение с unlogged table. Поскольку данные используются только в пределах транзакции, то каждая транзакция видит только данные, которые она сама и создала.
Это верно, но для TRUNCATE mytable триггер выполняется немедленно, и это может быть проблемой. Рассмотрим такой пример:
транзакция 1: begin; TRUNCATE mytable;…… commit; --начинается раньше, но долгая
транзакция 2: begin; Insert into mytable; commit; — позже и короткая
Но транзакции 2 придётся ожидать окончания транзакции 1, поскольку транзакция 1 заблокировала таблицу mytable_count
И надо учитывать, что deferred constraint trigger может привести к такой проблеме:
в транзакции сначала вставили\удалили строки в mytable, а позже есть логика, завязанная на количество записей в mytable, и берём мы его из mytable_count, но в mytable_count не учтены вставили\удаления, выполненные в этой транзакции