Redshift 是否有效地（即二进制搜索）找到在列 A 上排序的表块，用于条件 A= 的查询？
举个例子，假设有一个表 T 有约 500m 行，约 50 个字段，在字段 A 上分布和排序。字段 A 具有高基数 - 所以有约 4.5 m 不同的 A 值，其中的行数完全相同T：每个值约 100 行。
假设一个带有单个 XL 节点的 redshift 集群。
字段 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 磁盘块中。每个块的最小值和最大值作为元数据的一部分存储。如果一个范围受限的列是一个排序键，查询处理器能够使用最小值和最大值在表扫描期间快速跳过大量块。例如，如果一个表存储了按日期排序的 5 年数据，并且一个查询指定一个月的日期范围，最多可以排除98%的磁盘块，如果数据没有排序，则需要扫描更多的磁盘块（可能是全部）。有关这些优化的信息，请参阅选择分发键。 "
次要问题：
上述对排序键的跳过扫描的复杂性是多少？它是线性的（ O(n) ）还是二进制搜索的某种变体（ O(logn) ）？
如果对键进行排序 - 是否跳过唯一可用的优化？
这种“跳过”优化在解释计划中会是什么样子？
以上解释是否是此查询的最佳解释？
在这种情况下，预计红移最快的结果是什么？
vanilla ParAccel 在这个用例中是否有不同的行为？