如果我理解正确,完全随机的 UUID 值会创建零散的索引。或者,更准确地说,缺少公共(public)前缀会阻止索引中的密集 trie 存储。
我看到有人建议使用 uuid_generate_v1() 或 uuid_generate_v1mc() 而不是 uuid_generate_v4() 来避免这个问题。
但是,UUID 规范的版本 1 似乎首先具有 ID 的低位,从而阻止了共享前缀。此外,这个时间戳是 60 位,这似乎有点过头了。
相比之下,一些数据库提供非标准 UUID 生成器,时间戳在前 32 位,然后是随机的 12 字节。参见 Datomic 的 Squiid,例如 1 , 2 .
在 Postgres 中像这样使用“Squiids”真的有意义吗?如果是这样,我如何使用 pgplsql 高效地生成此类 ID?
最佳答案
请注意,仅当您不删除值并且所有更新都产生 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);
关于postgresql - 在 Postgres 中生成非碎片 UUID?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44664279/