为什么子查询中的 distinct on 会损害 PostgreSQL 的性能？

Question

我有一个表 users，其中包含字段 id 和 email。 id 是主键，email 也是索引。

database> \d users
+-----------------------------+-----------------------------+-----------------------------------------------------+
| Column                      | Type                        | Modifiers                                           |
|-----------------------------+-----------------------------+-----------------------------------------------------|
| id                          | integer                     |  not null default nextval('users_id_seq'::regclass) |
| email                       | character varying           |                                                     |
+-----------------------------+-----------------------------+-----------------------------------------------------+
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
    "index_users_on_email" UNIQUE, btree (email)

如果我在子查询中使用 distinct on (email) 子句查询表，我会受到显着的性能损失。

database> explain (analyze, buffers)
   select
     id
   from (
     select distinct on (email)
       id
     from
       users
   ) as t
   where id = 123
+-----------------------------------------------------------------------------------------------------------------------------+
| QUERY PLAN                                                                                                                  |
|-----------------------------------------------------------------------------------------------------------------------------|
| Subquery Scan on t  (cost=8898.69..10077.84 rows=337 width=4) (actual time=221.133..250.782 rows=1 loops=1)                 |
|   Filter: (t.id = 123)                                                                                                      |
|   Rows Removed by Filter: 67379                                                                                             |
|   Buffers: shared hit=2824, temp read=288 written=289                                                                       |
|   ->  Unique  (cost=8898.69..9235.59 rows=67380 width=24) (actual time=221.121..247.582 rows=67380 loops=1)                 |
|         Buffers: shared hit=2824, temp read=288 written=289                                                                 |
|         ->  Sort  (cost=8898.69..9067.14 rows=67380 width=24) (actual time=221.120..239.573 rows=67380 loops=1)             |
|               Sort Key: users.email                                                                                         |
|               Sort Method: external merge  Disk: 2304kB                                                                     |
|               Buffers: shared hit=2824, temp read=288 written=289                                                           |
|               ->  Seq Scan on users  (cost=0.00..3494.80 rows=67380 width=24) (actual time=0.009..9.714 rows=67380 loops=1) |
|                     Buffers: shared hit=2821                                                                                |
| Planning Time: 0.243 ms                                                                                                     |
| Execution Time: 251.258 ms                                                                                                  |
+-----------------------------------------------------------------------------------------------------------------------------+

将此与distinct on (id) 进行比较，其成本不到上一个查询的千分之一。

database> explain (analyze, buffers)
   select
     id
   from (
     select distinct on (id)
       id
     from
       users
   ) as t
   where id = 123
+-----------------------------------------------------------------------------------------------------------------------------+
| QUERY PLAN                                                                                                                  |
|-----------------------------------------------------------------------------------------------------------------------------|
| Unique  (cost=0.29..8.31 rows=1 width=4) (actual time=0.021..0.022 rows=1 loops=1)                                          |
|   Buffers: shared hit=3                                                                                                     |
|   ->  Index Only Scan using users_pkey on users  (cost=0.29..8.31 rows=1 width=4) (actual time=0.020..0.020 rows=1 loops=1) |
|         Index Cond: (id = 123)                                                                                              |
|         Heap Fetches: 1                                                                                                     |
|         Buffers: shared hit=3                                                                                               |
| Planning Time: 0.090 ms                                                                                                     |
| Execution Time: 0.034 ms                                                                                                    |
+-----------------------------------------------------------------------------------------------------------------------------+

这是为什么？

我遇到的真正问题是我正在尝试创建一个视图，该视图执行 distinct on 一个不唯一的索引列并且性能非常糟糕。

Answer 1

逻辑差异

id 和 email 两列都是 UNIQUE。但只有id 是NOT NULL。 （PRIMARY KEY 列始终是。）NULL 值不被视为相等，具有UNIQUE 约束（或索引）的列中允许多个NULL 值。那是根据标准SQL。见：

• Allow null in unique column

但DISTINCT 或DISTINCT ON 认为NULL 值相等。 The manual:

显然，如果两行至少不同 一列值。 在此比较中，空值被视为相等。

我的大胆强调。延伸阅读：

• Select first row in each GROUP BY group?

在您的第二个查询中，distinct on (id) 是一个逻辑空操作：保证结果与没有DISTINCT ON 的结果相同。而且由于id = 123 上的外部SELECT 过滤器，Postgres 可以去除噪音并完成非常便宜的仅索引扫描。

另一方面，在您的第一个查询中，如果email IS NULL 有多个行，distinct on (email) 可能实际上会执行某些操作。然后 Postgres 必须根据给定的排序顺序选择第一个 id。由于没有ORDER BY，因此会导致任意选择。但是带有谓词where id = 123 的外部SELECT 可能取决于结果。整个查询在性质上与第一个完全不同 - 并且被设计破坏。

巧遇

除此之外，还有两个“幸运”的发现：

Sort Method: external merge  Disk: 2304kB

提及“磁盘”表示work_mem 不足。见：

• Configuration parameter work_mem in PostgreSQL on Linux

          ->  Seq Scan on users  (cost=0.00..3494.80 rows=67380 

在我的测试中，我总是在这里进行索引扫描。表示您的设置存在臃肿的索引或其他问题。

有用的比较？

比较无济于事。我们可能会从中学到一些东西 将第一个查询与此查询进行比较 - 在​​切换 PK 和 UNIQUE 列的角色后：

select email
from  (select distinct on (id) email from users) t
where email = 'user123@foo.com';

或者通过比较第二个查询和这个 - 尝试使用 UNIQUE 列而不是 PK 列：

select email
from  (select distinct on (email) email from users) t
where email = 'user123@foo.com';

我们了解到 PK 和 UNIQUE 约束对查询计划没有不同的影响。 Postgres 不使用元信息来偷工减料。 PK 实际上会对GROUP BY 产生影响。见：

• Unexpected behaviour for GROUP BY query

所以这行得通：

SELECT email
FROM  (
   SELECT email -- no aggregate required, because id = PK
   FROM   users
   GROUP  BY id  -- !
   ) t
WHERE email = 'user123@foo.com';

但是在切换id 和email 之后同样不起作用。我在小提琴中添加了一些演示：

db小提琴here

那么？

这两个查询都是无意义的，原因不同。我看不出他们如何帮助您解决真正的问题：

我遇到的真正问题是，我正在尝试创建一个视图，该视图在不是唯一的的索引列上确实不同，并且性能非常糟糕。

我们需要查看您的真实查询 - 以及您设置的所有其他相关详细信息。可能有解决方案，但这可能远远超出了关于 SO 的问题的范围。考虑聘请顾问。或者考虑使用以下方法之一来优化性能：

• Optimize GROUP BY query to retrieve latest row per user