如果我理解正确,完全随机的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);
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。