4

Postgres クエリ プランを調べたところ、上のステップの開始時刻が下のステップの終了時刻と重なっていないことに気付きました。

このクエリのフィールド名が編集されました。

以下に示すように、クエリ実行プログラムには 2 つのステップがあります。下位ステップの「インデックス スキャン」は 5730.776 (実際の時間) で終了しますが、ルート ステップは 19199.316 (実際の時間) で始まります。私の質問は、 5730.776 から 19199.316 の間に何が起こったのですか?

ポストグル 9.1

explain analyze select a_id,b_id,c_id,d_id,e_id,mydate, f,sum(used) used
from report A where mydate >= '2013-05-01' and mydate  <= '2013-08-30'
group by a_id,b_id,c_id,d_id,e_id,date,f;
                                                                                                      QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=412378.59..418074.28 rows=569569 width=70) (actual time=**19199.316**..25518.672 rows=4935988 loops=1)
   ->  Index Scan using report_dateonly_idx on report a  (cost=0.00..298464.83 rows=5695688 width=70) (actual time=0.033..**5730.776** rows=5816028 loops=1)
         Index Cond: ((date >= '2013-05-01 00:00:00'::timestamp without time zone) AND (date <= '2013-08-30 00:00:00'::timestamp without time zone))
 Total runtime: 29148.500 ms
4

2 に答える 2

4

クエリ プランの理解に関するこの一連のブログ投稿に興味があるかもしれません。

あなたの場合、各コスト/タイミングの2つの数字が何を表しているかを誤解しています。それらは操作の開始と終了ではなく、(大まかに)最初の行までのコスト/時間、およびすべての行を含むコスト/時間です。

Depesz は、"cost=22.88..23.61" の並べ替え操作の例を示しています。データを返す前にすべてを並べ替える必要があるため、データを準備するためのコストが高くなります。ソートされたリストをスプールしているだけなので、実際に返すコストははるかに低くなります。

したがって、あなたの例では、19199.316 は HashAggregate が t=19199.316 まで実行を開始しないことを意味するのではなく、t=19199.316 まで HashAggregate からデータが出力されないことを意味します。

実際、HashAggregate は、インデックス スキャンがデータを返し始めるとすぐにデータの処理を開始します。これは t=0.033 です。t=5730.776 までに、インデックス スキャンは関連するすべての行を検出しましたが、HashAggregate はまだそれらを処理しています。t=19199.316 で、HashAggregate はその親 (この場合は最終結果) にデータを返し始める準備が整い、t=25518.672 でデータの返しが終了します。

Depezs には、クエリ プランを表形式に解釈するツールもあります。これがあなたの計画です。HashAggregate が 19787.896 の「排他的時間」を示していることに注意してください。これは、入力データがどこから来たかを無視して、ハッシュを実行するのにかかった時間です。

于 2013-09-22T13:15:13.610 に答える
1

観察された動作の理由: 統計が間違っています:

HashAggregate  (cost=412378.59..418074.28 rows=569569 width=70) (actual time=**19199.316**..25518.672 rows=4935988 loops=1)
 [expected] -----------------------------------^^^^^^       [actual rows found] > ------------------------ ^^^^^^^

これは 9 倍ずれており、結果が work_mem に収まると考えられるため、プランナーはハッシュ テーブル ベースの集計を選択します。最初は小さすぎて、数回サイズを変更する必要があり、workmem に収まらない場合は、ディスクにスピルする必要さえあります。

ところで: この種の計画を再現することはできませんでした。ビットマップ インデックス スキャンを取得し続けます。

于 2013-09-22T21:00:39.047 に答える