Во всяком случае очевидной возможности генерировать uuid последовательно нет.

Производительность insert - в postgresql данные не кластеризованы. Поэтому монотонная или случайная последовательность записываемых значений - значения не имеет.

Ролг Хупин, по индексам я немного задумался ещё когда предыдущее сообщение писал. К сожалению, не могу точно ответить, что именно представлено в postgresql под названием B-tree.

Классическая структура b-tree, если правильно помню, оптимально работает только со случайным заполнением данными. Возрастающая последовательность превращает дерево в простой неэффективный список. Производные от b-tree структуры (вроде красно-чёрных деревьев) с этим борются. Но что используется в реальном нынешнем мире и какие дополнительные внесены оптимизации в узкие места - я не знаю.

Локшин Марк, мне гугл выдал первой статью, на одну из которых ваша ссылка на вики и ссылается: http://algolist.manual.ru/ds/
авторМожно доказать, что при последовательном включении в дерево случайных данных получается именно среднее время выполнения операций. Однако, если входные данные, например, образуют возрастающую последовательность, то получается список и все преимущество дерева потеряно.
Да, память и внимательность таки подвели, только не с той стороны, откуда ждал. Это сказано про binary tree, а b-tree - именно уже сбалансированное дерево. Надо будет перечитать алгоритмы и структуры.

LeXa NalBat, то есть в менее экстремальной варианте, когда индексы и новые данные помещаются в shared buffers, стоимость вставки одной записи будет одинаковая и для случайного и для нового последовательного значения, правильно? Стоимость вставки группы записей (но ещё влезаем в память) - случайное распределение создаст больше грязных страничек и больше работы чекпойнту.
Что-нибудь критичное изменится, если говорить не про два copy (один со случайными, второй с последовательными ключами), а про конкурентные транзакции? Для простоты, транзакции делают только один insert в табличку, где есть только primary key, других индексов и FK нет. На сколько понимаю, последовательные ключи будут сильнее драться за блокировки на странички индекса, но это short-term локи и заметным образом влиять не будут.