PostgreSQLの主キーとしてのUUIDは、インデックスのパフォーマンスを低下させますか？

（私はHeroku Postgresに取り組んでいます）

いくつかのシステムでは主キーとしてUUIDを使用しており、うまく機能します。

uuid-osspを使用することをお勧めします拡張機能、さらにpostgresにUUIDを生成させる：

heroku pg:psql
psql (9.1.4, server 9.1.6)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

dcvgo3fvfmbl44=> CREATE EXTENSION "uuid-ossp"; 
CREATE EXTENSION  
dcvgo3fvfmbl44=> CREATE TABLE test (id uuid primary key default uuid_generate_v4(), name text);  
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE  
dcvgo3fvfmbl44=> \d test
                 Table "public.test"  
Column | Type |              Modifiers              
--------+------+-------------------------------------  
id     | uuid | not null default uuid_generate_v4()  name   | text |  
Indexes:
    "test_pkey" PRIMARY KEY, btree (id)

dcvgo3fvfmbl44=> insert into test (name) values ('hgmnz'); 
INSERT 0 1 
dcvgo3fvfmbl44=> select * from test;
                  id                  | name  
--------------------------------------+-------   
 e535d271-91be-4291-832f-f7883a2d374f | hgmnz  
(1 row)

パフォーマンスへの影響を編集する

常にワークロードによって異なります。

整数の主キーには、like-dataが互いに接近している局所性という利点があります。これは、たとえば次の場合に役立ちます。WHERE id between 1 and 10000などの範囲タイプのクエリロックの競合はさらに悪化しますが。

読み取りワークロードが常に主キールックアップを行うという点で完全にランダムである場合、測定可能なパフォーマンスの低下はないはずです。より大きなデータ型に対してのみ料金を支払います。

このテーブルにたくさん書いていますか、そしてこのテーブルはとても大きいですか？私はこれを測定していませんが、そのインデックスを維持することに影響がある可能性があります。ただし、多くのデータセットの場合、UUIDは問題ありません。また、識別子としてUUIDを使用すると、いくつかの優れたプロパティがあります。

最後に、問題となったUUID PKで十分な大きさのテーブルを実行したことがないため、これについて話し合ったりアドバイスしたりするのに最も適した人物ではない可能性があります。 YMMV。（そうは言っても、アプローチで問題が発生した人の話を聞きたいです！）