array_agg（）が非集約ARRAY（）コンストラクターより遅いのはなぜですか？

8.4より前のPostgreSQL向けに作成された古いコードをレビューしたところ、本当に気の利いたものが見つかりました。当時はカスタム関数でこれの一部を実行していたことを覚えていますが、事前にarray_agg()どのようなものかを忘れていました。レビューのために、現代の集計はこのように書かれています。

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

しかし、昔々、このように書かれていました、

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

それで、私はいくつかのテストデータでそれを試しました。

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

結果は驚くべきものでした。.#OldSchoolCoolの方法は非常に高速で、25％高速化されました。さらに、ORDERを使用せずに単純化すると、同じ遅延が示されました。

# 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)

それで、ここで何が起こっているのか。内部関数であるarray_aggが、プランナーのSQLブードゥー教よりもずっと遅いのはなぜですか？

「gcc（Ubuntu 6.2.0-5ubuntu12）6.2.0 20161005、64ビットでコンパイルされたx86_64-pc-linux-gnuでのPostgreSQL 9.5.5の使用」

ARRAYコンストラクターについて「古い」または「時代遅れ」なものは何もありません（それが何であるかARRAY(SELECT x FROM foobar)）。相変わらずモダンです。単純な配列集約に使用します。

マニュアル：

サブクエリの結果から配列を構築することもできます。この形式では、配列コンストラクターはキーワードにARRAY続いて括弧で囲まれた（括弧で囲まれていない）サブクエリで記述されます。

集約関数はarray_agg()、はるかにそれが中に統合することができるという点で汎用性がSELECT同じで複数の列、おそらくより多くの集約とリストSELECT、および任意の基を用いて形成することができますGROUP BY。一方、ARRAYコンストラクターはSELECT、単一の列を返すことから単一の配列のみを返すことができます。

私はソースコードを勉強しませんでしたが、はるかに汎用性の高いツールがより高価であることは明らかです。

Erwinが受け入れた答えは、次のように追加できると思います。

通常、元の質問のように一時テーブル（インデックスなし）の代わりに、インデックス付きの通常のテーブルを使用します。などの集計でARRAY_AGGは、集計中に並べ替えが行われたときに既存のインデックスを活用できないことに注意してください。

たとえば、次のクエリを想定します。

SELECT ARRAY(SELECT c FROM t ORDER BY id)

インデックスがonのt(id, ...)場合、インデックスを使用して、順次スキャンをオンtにし、その後にソートをオンにすることができt.idます。さらに、配列（ここではc）にラップされている出力列がインデックスの一部（インデックスon t(id, c)またはインクルードインデックスonなどt(id) include(c)）である場合、これはインデックスのみのスキャンである可能性もあります。

それでは、クエリを次のように書き換えましょう。

SELECT ARRAY_AGG(c ORDER BY id) FROM t

現在、集計はインデックスを使用せず、メモリ内の行を並べ替える必要があります（ディスク上の大きなデータセットの場合はさらに悪い）。これは、常に順次スキャンであり、tその後にaggregation + sortが続きます。

私の知る限り、これは公式文書には記載されていませんが、ソースから派生する可能性があります。これは、v11を含む現在のすべてのバージョンに当てはまります。