Mengapa array_agg () lebih lambat daripada konstruktor ARRAY () non-agregat?

Saya baru saja meninjau beberapa kode lama yang ditulis untuk pra-8.4 PostgreSQL , dan saya melihat sesuatu yang sangat bagus. Saya ingat memiliki fungsi khusus melakukan beberapa hal ini pada hari itu, tapi saya lupaarray_agg() . Untuk ulasan, agregasi modern ditulis seperti ini.

SELECT array_agg(x ORDER BY x DESC) FROM foobar;

Namun, pada suatu waktu, ditulis seperti ini,

SELECT ARRAY(SELECT x FROM foobar ORDER BY x DESC);

Jadi, saya mencobanya dengan beberapa data uji ..

CREATE TEMP TABLE foobar AS
SELECT * FROM generate_series(1,1e7)
  AS t(x);

Hasilnya mengejutkan .. Cara #OldSchoolCool jauh lebih cepat: kecepatan 25%. Apalagi menyederhanakannya tanpa ORDER, menunjukkan kelambatan yang sama.

# EXPLAIN ANALYZE SELECT ARRAY(SELECT x FROM foobar);
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Result  (cost=104425.28..104425.29 rows=1 width=0) (actual time=1665.948..1665.949 rows=1 loops=1)
   InitPlan 1 (returns $0)
     ->  Seq Scan on foobar  (cost=0.00..104425.28 rows=6017728 width=32) (actual time=0.032..716.793 rows=10000000 loops=1)
 Planning time: 0.068 ms
 Execution time: 1671.482 ms
(5 rows)

test=# EXPLAIN ANALYZE SELECT array_agg(x) FROM foobar;
                                                        QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=119469.60..119469.61 rows=1 width=32) (actual time=2155.154..2155.154 rows=1 loops=1)
   ->  Seq Scan on foobar  (cost=0.00..104425.28 rows=6017728 width=32) (actual time=0.031..717.831 rows=10000000 loops=1)
 Planning time: 0.054 ms
 Execution time: 2174.753 ms
(4 rows)

Jadi, apa yang terjadi di sini. Mengapa array_agg , fungsi internal jauh lebih lambat dari voodoo SQL perencana?

Menggunakan " PostgreSQL 9.5.5 pada x86_64-pc-linux-gnu, dikompilasi oleh gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005, 64-bit"

Tidak ada "sekolah tua" atau "ketinggalan zaman" tentang konstruktor ARRAY (Itulah apa ARRAY(SELECT x FROM foobar)). Ini modern seperti biasa. Gunakan untuk agregasi array sederhana.

Manual:

Dimungkinkan juga untuk membuat array dari hasil subquery. Dalam bentuk ini, konstruktor array ditulis dengan kata kunci ARRAYdiikuti oleh subquery yang di-kurung (tidak dikurung).

Fungsi agregatarray_agg() jauh lebih fleksibel dalam hal itu dapat diintegrasikan dalam SELECTdaftar dengan lebih banyak kolom, mungkin lebih banyak agregasi dalam yang sama SELECT, dan kelompok-kelompok sewenang-wenang dapat dibentuk dengan GROUP BY. Sedangkan konstruktor ARRAY hanya dapat mengembalikan satu array dari SELECTkolom tunggal yang dikembalikan.

Saya tidak mempelajari kode sumber, tetapi akan tampak jelas bahwa alat yang jauh lebih fleksibel juga lebih mahal.

Saya percaya jawaban yang diterima oleh Erwin dapat ditambahkan dengan yang berikut.

Biasanya, kami bekerja dengan tabel biasa dengan indeks, bukan tabel sementara (tanpa indeks) seperti pada pertanyaan awal. Penting untuk dicatat bahwa agregasi, seperti ARRAY_AGG, tidak dapat meningkatkan indeks yang ada saat penyortiran dilakukan selama agregasi .

Misalnya, asumsikan kueri berikut:

SELECT ARRAY(SELECT c FROM t ORDER BY id)

Jika kita memiliki indeks aktif t(id, ...), indeks dapat digunakan, mendukung pemindaian berurutan tdiikuti oleh semacam t.id. Selain itu, jika kolom output yang dibungkus dalam array (di sini c) adalah bagian dari indeks (seperti indeks pada t(id, c)atau indeks termasuk padat(id) include(c) ), ini bahkan bisa menjadi hanya indeks-scan.

Sekarang, mari kita tulis ulang kueri itu sebagai berikut:

SELECT ARRAY_AGG(c ORDER BY id) FROM t

Sekarang, agregasi tidak akan menggunakan indeks dan harus mengurutkan baris dalam memori (atau bahkan lebih buruk untuk set data besar, pada disk). Ini akan selalu menjadi pemindaian berurutan pada tdiikuti oleh agregasi + semacam .

Sejauh yang saya tahu, ini tidak didokumentasikan dalam dokumentasi resmi, tetapi dapat diturunkan dari sumbernya. Ini harus menjadi kasus untuk semua versi saat ini, termasuk v11.