Мне интересно узнать о влиянии производительности использования непоследовательного UUID в качестве первичного ключа в таблице, который станет довольно большим в PosgreSQL.
В СУБД, использующих кластерное хранилище для записей в таблице, указано, что использование UUID увеличивает стоимость вставок из-за необходимости чтения с диска, чтобы найти страницу данных, в которую будет выполняться вставка, после того, как таблица слишком велика для хранения в памяти. Насколько я понимаю, Postgres не поддерживает кластеризацию строк на вставках, поэтому я предполагаю, что в Postgres, использующем UUID PK, не повредит производительность этой вставки.
Но я бы подумал, что это делает вставку в индекс, что ограничение первичного ключа создает гораздо более дорогие, как только таблица будет большой, потому что ее нужно будет постоянно читать с диска, чтобы обновить индекс при вставке новых данных. В то время как с последовательным ключом индекс будет обновляться только на кончике, который всегда будет в памяти.
Предполагая, что я правильно понимаю влияние производительности на индекс, есть ли способ исправить это или UUID просто не хороший PK на большой, не разделенной таблице?