ist*_*ele 2 postgresql identity amazon-redshift
当我从一个带有身份、主键和排序键的表中选择到另一个带有自己的一组身份、主键和排序键的表时,我最初遇到了这个问题。它没有尊重定义的 (1,1) 身份,而是执行 (1,8)(有时为 3,8)。我想可能是因为原始表已排序?为了弄清楚发生了什么,我做了一个更简单的查询和数据,并在多个红移集群中找到了一个可重现的示例。拿这个测试例子:
drop table if exists test;
create temp table test (id int identity(1,1) not null
, value varchar(16)
, primary key (id))
diststyle all
sortkey (id);
insert into test (value) select 'a';
insert into test (value) select 'b';
insert into test (value) select 'c' union select 'd';
insert into test (value) values ('e'), ('f'), ('g');
select * from test;
Run Code Online (Sandbox Code Playgroud)
我得到的输出是:
id value
1 a
2 b
9 c
10 d
3 e
4 f
5 g
Run Code Online (Sandbox Code Playgroud)
您会注意到标识列没有正确递增。我有其他集群上的朋友试过这个,他们得到了 20、27 和 65、60 的 c 和 d 列,而其他列是有序的。请注意,尽管 id 列的物理顺序不正确,但输出仍按输入的排序键/顺序正确“排序”。
我能想到的第一次发现这个奇怪的原始结果与测试查询之间的唯一相似之处是联合已排序并且我的表上有一个排序键。
关于为什么会发生这种情况以及如何解决它的其他想法是受欢迎的。
小智 5
Redshift 标识列不保证是由标识跳过值定义的增量。但是,可以保证这些值永远不会发生冲突(即它始终是唯一的)。
跳过价值是因为 Redshift 的分布式架构。每个节点在数轴上保留一些值(n mod x,其中 x 是集群中的节点数)。因此,如果所有节点没有获得相同数量的行,您将看到标识值中的跳跃。
| 归档时间: |
|
| 查看次数: |
3037 次 |
| 最近记录: |