postgresql - PostgreSQL:DISTINCT中的最新行性能低于GROUP BY中的最大行

我有一个情况，我想更好地理解：
我有一个表t有两行和一个索引：

CREATE TABLE t (
  refid                 BIGINT NOT NULL,
  created               TIMESTAMPTZ NOT NULL
);
CREATE INDEX t_refid_created ON t (refid, created);

为了获得每个不同created的最新（具有最大refid值）行，我编写了两个查询：

-- index only scan t_refid_created_desc_idx
SELECT DISTINCT ON (refid) * FROM t
ORDER BY refid, created DESC;

-- index scan t_refid_created_idx
SELECT refid, max(created) FROM t GROUP BY refid;

当t有大约16M行并且refid中的方差约为500个不同值时，第二个查询返回的速度比第二个查询快得多。
起初我认为，因为我是按created DESC排序的，所以它需要进行反向索引扫描，并且当从高方差值（创建）开始时。所以我添加了以下索引：

CREATE index t_refid_created_desc_idx ON t (refid, created DESC);

确实使用了它（而不是对上一个索引进行反向扫描），但没有任何改进。
如果我理解正确，第二个查询将聚合refid，然后扫描每个聚合以找到maxcreated值。这听起来像是很多工作。
据我所知，第一个查询应该只是遍历索引的第一部分，然后对于每个refid都应该使用索引的第二部分，取第一个值。
显然情况并非如此，SELECT DISTINCT查询所需时间是GROUP BY的两倍。
我错过了什么？
以下是第一个和第二个查询的EXPLAIN ANALYZE输出：

Unique  (cost=0.56..850119.78 rows=291 width=16) (actual time=0.103..13414.913 rows=469 loops=1)
  ->  Index Only Scan using t_refid_created_desc_idx on t  (cost=0.56..808518.47 rows=16640527 width=16) (actual time=0.102..12113.454 rows=16640527 loops=1)
        Heap Fetches: 16640527
Planning time: 0.157 ms
Execution time: 13415.047 ms

Finalize GroupAggregate  (cost=599925.13..599932.41 rows=291 width=16) (actual time=3454.350..3454.884 rows=469 loops=1)
  Group Key: refid
  ->  Sort  (cost=599925.13..599926.59 rows=582 width=16) (actual time=3454.344..3454.509 rows=1372 loops=1)
        Sort Key: refid
        Sort Method: quicksort  Memory: 113kB
        ->  Gather  (cost=599837.29..599898.40 rows=582 width=16) (actual time=3453.194..3560.602 rows=1372 loops=1)
              Workers Planned: 2
              Workers Launched: 2
              ->  Partial HashAggregate  (cost=598837.29..598840.20 rows=291 width=16) (actual time=3448.225..3448.357 rows=457 loops=3)
                    Group Key: refid
                    ->  Parallel Seq Scan on t  (cost=0.00..564169.53 rows=6933553 width=16) (actual time=0.047..2164.459 rows=5546842 loops=3)
Planning time: 0.157 ms
Execution time: 3561.727 ms

第一个查询大约在10秒内运行，而第二个查询在2秒内实现相同的结果！甚至不用索引！
我在用PostgreSQL 10.5。

最佳答案

我无法回答为什么DISTINCT ON不考虑第二个计划。从成本估算我们可以看出PostgreSQL认为它更便宜。
我想没有人实施过将DISTINCT推向并行计划的做法。你可以问一下邮寄名单。
然而，第一个查询的问题是1600万个堆获取。这意味着这实际上是一个正常的索引扫描！从计划者的角度看，这是一个错误的估计。
如果我是对的，那么清除可见性映射的表上的VACUUM应该会大大改进第一个查询。

RefID

postgresql - PostgreSQL:DISTINCT中的最新行性能低于GROUP BY中的最大行