为什么SELECT *比按名称选择所有列（以不同的列顺序）要快得多？

在具有a，b，c，d，e，f，g，h，i，j，k列的表上，我得到：

select * from misty order by a limit 25;
Time: 302.068 ms

和：

select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25;
Time: 1258.451 ms

有没有一种方法可以使按列选择速度如此之快？

更新：

在表上没有索引，新创建了一个

这是EXPLAIN ANALYZE，似乎不太有用：

explain analyze select * from misty order by a limit 25;

Limit  (cost=43994.40..43994.46 rows=25 width=190) (actual time=404.958..404.971 rows=25 loops=1)
->  Sort  (cost=43994.40..45731.11 rows=694686 width=190) (actual time=404.957..404.963 rows=25 loops=1)
     Sort Key: a
     Sort Method: top-N heapsort  Memory: 28kB
     ->  Seq Scan on misty  (cost=0.00..24390.86 rows=694686 width=190) (actual time=0.013..170.945 rows=694686 loops=1)
Total runtime: 405.019 ms
(6 rows)

和：

explain analyze select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25;

Limit  (cost=43994.40..43994.46 rows=25 width=190) (actual time=1371.735..1371.745 rows=25 loops=1)
->  Sort  (cost=43994.40..45731.11 rows=694686 width=190) (actual time=1371.733..1371.736 rows=25 loops=1)
     Sort Key: a
     Sort Method: top-N heapsort  Memory: 28kB
     ->  Seq Scan on misty  (cost=0.00..24390.86 rows=694686 width=190) (actual time=0.015..516.355 rows=694686 loops=1)
Total runtime: 1371.797 ms
(6 rows)

这被发布到pgsql-hackers邮件列表中，我试图在那里简短回答。看来，如果目标列表（指定的列）与关系的元组描述符完全匹配，即在列数和顺序上都匹配，则基础扫描可以返回由封闭的Sort节点直接消耗的元组。另一方面，如果目标列表不匹配（顺序或指定列数不匹配），则扫描将返回一种元组形式，这需要Sort的数据准备步骤来执行额外的工作（从内部元组格式转换为由排序代码直接使用的格式）。

顺便说一句，“ *”在内部转换为一个列表，该列表（直观地）与该关系的元组描述符匹配。

编辑：如果您查看后者的EXPLAIN ANALYZE的Seq Scan的实际时间，则可以看到它比前者更多。之所以发生这种情况，是因为扫描执行了额外的投影步骤（即将堆元组转换为内部values []，nulls []格式）。并且由于这种情况发生，上层Sort节点必须在其数据初始化中做额外的工作，即将其转换回实际排序步骤可以理解的元组格式。从Sort的启动成本中可以明显看出这一点。在前一种情况下不会发生这种情况。也就是说，扫描都将按原样返回元组，并且sort的初始化步骤只是将其复制。