postgresql – 在Postgres中生成非碎片UUID？

发布时间：2020-12-13 18:10:35 所属栏目：百科来源：网络整理

导读：如果我理解正确,完全随机的UUID值会创建碎片索引.或者,更准确地说,缺少公共前缀会阻止索引中的密集存储. 我已经看到了使用uuid_generate_v1()或uuid_generate_v1mc()而不是uuid_generate_v4()来避免这个问题的建议. 但是,似乎UUID规范的版本1首先具有ID的低

如果我理解正确,完全随机的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？

请注意,仅当您不删除值并且所有更新都生成 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);

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!