红移是否有效(即二进制搜索)发现,是在A列排序,以便与条件A的查询表中的一个块=？
作为一个例子,让有用〜500米行的表T,〜50个场,分布和分类上场A.字段A具有高基数-所以有〜4.5米不同的A值,其中恰好在相同的行数T:每个值约100行.
假设具有单个XL节点的红移群集.
字段A未压缩.所有其他字段都有一些表单压缩,如ANALYZE COMPRESSION所示.与未压缩的表相比,给出1:20的比率.
给出一个简单的查询:
select avg(B),avg(C) from
(select B,C from T where A = <val>)
在VACUUM和ANALYZE之后,给出了以下解释计划:
XN Aggregate (cost=1.73..1.73 rows=1 width=8)
-> XN Seq Scan on T (cost=0.00..1.23 rows=99 width=8)
Filter: (A = <val>::numeric)
此查询需要39秒才能完成.
主要问题是:这是红移的预期行为吗？
根据选择最佳
排序键的文档 :"如果对一列进行频繁范围过滤或相等过滤,请将该列指定为排序键.Redshift可以跳过读取该列的整个数据块,因为它会跟踪最小值以及存储在每个块上的最大列值,并且可以跳过不适用于谓词范围的块. "
在选择排序键时:
"依赖于排序数据的另一个优化是范围限制谓词的有效处理.Amazon Redshift将列数据存储在1 MB磁盘块中.每个块的最小值和最大值都存储为元数据的一部分.如果范围限制列是排序键,则查询处理器能够使用最小值和最大值在表扫描期间快速跳过大量块.例如,如果表存储按日期排序的五年数据,查询指定一个月的日期范围,从扫描中可以消除多达98%的磁盘块.如果数据未排序,则必须扫描更多磁盘块(可能全部).有关这些优化的信息,请参阅选择分发键. "
次要问题:
在排序键上进行上述跳过扫描的复杂性是多少？它是线性的(O(n))还是二元搜索的一些变体(O(logn))？
如果密钥已排序 - 正在跳过唯一可用的优化？
在解释计划中,这种"跳过"优化会是什么样子？
以上是解释此查询可能的最佳方法吗？
在这种情况下,可以预期红移最快的结果是什么？
vanilla ParAccel在这个用例中有不同的行为吗？