PostgreSQL UUID类型的性能

Question

我不是要重新启动UUID vs串行整数键辩论。 我知道任何一方都有有效的观点。 我在我的几个表中使用UUID作为主键。

• 列类型： "uuidKey" text NOT NULL
• 索引： CREATE UNIQUE INDEX grand_pkey ON grand USING btree ("uuidKey")
• 主键约束： ADD CONSTRAINT grand_pkey PRIMARY KEY ("uuidKey");

这是我的第一个问题; 使用PostgreSQL 9.4将列类型设置为UUID有什么性能优势？

文档http://www.postgresql.org/docs/9.4/static/datatype-uuid.html描述了UUID，但使用此类型而不是text类型除了类型安全之外还有什么好处？ 在字符类型文档中，它表明char(n)与PostgreSQL中的text没有任何优势。

提示：这三种类型之间没有性能差异，除了使用空白填充类型时增加的存储空间，以及一些额外的CPU周期来检查存储到长度受限列中的长度。 虽然character（n）在其他一些数据库系统中具有性能优势，但PostgreSQL没有这样的优势; 事实上，由于额外的存储成本，字符（n）通常是三者中最慢的。 在大多数情况下，应该使用文本或字符变化。

我并不担心磁盘空间，我只是想知道我是否值得花时间对UUID和文本列类型进行基准测试？

第二个问题，哈希与b树索引。 在排序UUID键时没有意义，因此b-tree与哈希索引相比还有其他优势吗？

Answer 1

UUID是16字节的值。 与text相同的是32字节值。 存储大小为：

select
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::text) as text_size,
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::uuid) as uuid_size;
 text_size | uuid_size 
-----------+-----------
        36 |        16

较小的表可以加快操作速度。

Answer 2

我们有一个大约30k行的表（由于特定的不相关的架构原因）将UUID存储在文本字段中并编制索引。 我注意到查询性能比我预期的要慢。 我创建了一个新的UUID列，复制在文本uuid主键中，并在下面进行比较。 2.652ms vs 0.029ms。 相当不同！

 -- With text index
    QUERY PLAN
    Index Scan using tmptable_pkey on tmptable (cost=0.41..1024.34 rows=1 width=1797) (actual time=0.183..2.632 rows=1 loops=1)
      Index Cond: (primarykey = '755ad490-9a34-4c9f-8027-45fa37632b04'::text)
    Planning time: 0.121 ms
    Execution time: 2.652 ms

    -- With a uuid index 
    QUERY PLAN
    Index Scan using idx_tmptable on tmptable (cost=0.29..2.51 rows=1 width=1797) (actual time=0.012..0.013 rows=1 loops=1)
      Index Cond: (uuidkey = '755ad490-9a34-4c9f-8027-45fa37632b04'::uuid)
    Planning time: 0.109 ms
    Execution time: 0.029 ms