Question

如果我理解正确，完全随机的UUID值会创建碎片索引。或者，更确切地说，缺少公共前缀会阻止索引中的密集存储。

我看到过使用uuid_generate_v1（）或uuid_generate_v1mc（）而不是uuid_generate_v4（）来避免这个问题的建议。

但是，似乎UUID规范的版本1首先具有ID的低位，从而阻止了共享前缀。此外，这个时间戳是60位，这似乎有点矫枉过正。

相比之下，一些数据库为非标准UUID生成器提供前导32位然后12字节随机性的时间戳。参见Datomic的Squuid's，例如1，2。

在Postgres中使用这样的“Squuids”实际上是否有意义？如果是这样，我怎么能用pgplsql有效地生成这样的ID？

Answer 1

请注意，仅当您不删除值且所有更新都生成heap only tuples时，插入连续索引条目才会产生更密集的索引。

如果您想要连续的唯一索引值，为什么不自己构建它们？

您可以将clock_timestamp()以微秒为bigint使用，并附加循环序列中的值：

CREATE SEQUENCE seq MINVALUE 0 MAXVALUE 999 CYCLE;

SELECT CAST(
          floor(
             EXTRACT(epoch FROM t)
          ) AS bigint
       ) % 1000000 * 1000000000
     + CAST(
          to_char(t, 'US') AS bigint
       ) * 1000
     + nextval('seq')
FROM (SELECT clock_timestamp()) clock(t);

在Postgres中生成非碎片UUID？

1 个答案: