Mengapa SELECT * jauh lebih cepat daripada memilih semua kolom (dalam urutan kolom yang berbeda) dengan nama?

Di atas meja dengan kolom a, b, c, d, e, f, g, h, i, j, k saya mendapatkan:

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

Dan:

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

Apakah ada cara untuk membuat kolom pilih dengan cepat?

Memperbarui:

Tidak ada indeks di atas meja, yang baru dibuat

Berikut adalah EXPLAIN ANALYZE, sepertinya tidak terlalu membantu:

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)

Dan:

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)

Ini diposting ke milis pgsql-hacker dan saya mencoba menjawab secara singkat di sana. Tampaknya jika daftar target (kolom yang ditentukan) cocok dengan deskriptor tuple relasi, yaitu, baik dalam jumlah kolom dan urutan, maka pemindaian yang mendasarinya dapat mengembalikan tupel yang langsung dikonsumsi oleh node Urut yang terlampir. Di sisi lain, jika daftar target tidak cocok (baik dalam urutan atau jumlah kolom yang ditentukan), pemindaian mengembalikan bentuk tupel yang memerlukan langkah persiapan data Sortir untuk melakukan pekerjaan tambahan (mengkonversi dari format tuple internal ke format langsung dikonsumsi oleh kode penyortiran).

Omong-omong, '*' diubah secara internal menjadi daftar yang (secara intuitif) cocok dengan deskriptor tuple relasi.

EDIT: Jika Anda melihat waktu aktual Seq Scan EXPLAIN ANALYZE Anda yang terakhir, Anda dapat melihatnya lebih dari sekadar former. Itu terjadi karena pemindaian melakukan langkah proyeksi tambahan (yaitu, mengubah tumpukan tumpukan menjadi nilai internal [], format nulls []). Dan karena itu terjadi, simpul Sortir atas harus melakukan pekerjaan ekstra dalam inisialisasi datanya, yaitu mengubahnya kembali ke format tuple yang dipahami oleh langkah sortasi. Itu terbukti dari biaya awal penyortiran. Itu tidak terjadi dalam kasus sebelumnya. Artinya, kedua pemindaian mengembalikan tuple sebagaimana adanya dan langkah inisialisasi sort hanya menyalinnya.