postgresql - 对于不存在的行，Redshift SELECT * 性能与 COUNT(*)

Question

当我运行 2 个看似相似的查询时，我对 Redshift 正在做什么感到困惑。两者都不应该返回结果(查询不存在的配置文件)。具体来说:

SELECT * FROM profile WHERE id = 'id_that_doesnt_exist' and project_id = 1;
  Execution time: 36.75s

对比

SELECT COUNT(*) FROM profile WHERE id = 'id_that_doesnt_exist' and project_id = 1;
  Execution time: 0.2s

鉴于该表按 project_id 然后是 id 排序，我会认为这只是一个键查找。 SELECT COUNT(*) ... 在 0.2 秒内返回 0 个结果，这正是我所期望的。 SELECT * ... 在 37.75 秒内返回 0 个结果。对于相同的结果，这是一个巨大的差异，我不明白为什么？

如果它有助于架构如下:

CREATE TABLE profile (
    project_id integer not null,
    id varchar(256) not null,
    created timestamp not null,
    /* ... approx 50 other columns here */
)
DISTKEY(id)
SORTKEY(project_id, id);

从 SELECT COUNT(*) ... 解释

XN Aggregate  (cost=435.70..435.70 rows=1 width=0)
  ->  XN Seq Scan on profile  (cost=0.00..435.70 rows=1 width=0)
        Filter: (((id)::text = 'id_that_doesnt_exist'::text) AND (project_id = 1))

从 SELECT * ... 解释

XN Seq Scan on profile  (cost=0.00..435.70 rows=1 width=7356)
    Filter: (((id)::text = 'id_that_doesnt_exist'::text) AND (project_id = 1))

为什么非计数会慢很多？ Redshift 肯定知道该行不存在吗？

Answer 1

原因是:在许多 RDBMS 中，count(*) 问题的答案通常没有实际的数据扫描:仅来自索引或表统计信息。 Redshift 存储用于给出存在或不存在答案的 block 的最小值和最大值，例如在描述器案例中。如果请求值在最小/最大块边界内，则将仅对过滤字段数据执行扫描。如果请求的值是较低或较高的 block 边界，则将根据存储的统计信息更快地给出答案。在“select *”问题的情况下，RedShift 实际上会按照查询中的要求扫描所有列数据:“*”但仅按“where”子句中的列进行过滤。