不可解なことを説明する。 パート3

PG Day'16カンファレンスの準備として、PostgreSQLの興味深い側面を紹介し続けます。 そして本日、Explainシリーズの3番目の記事の翻訳を提供します。



このシリーズの以前の 投稿では、Explain分析の出力の1行を解釈する方法とその構造について書き、データ（Explainツリーのノード）を取得するための基本操作についても説明しました。



今日は、より複雑な操作に進みます。

機能スキャン

例：

$ explain analyze select * from generate_Series(1,10) i; QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Function Scan on generate_series i (cost=0.00..10.00 rows=1000 width=4) (actual time=0.012..0.013 rows=10 loops=1) Total runtime: 0.034 ms (2 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

概して、それは非常に単純なので、何かを説明する必要は特にありません。 しかし、この操作は次の例で使用されるため、少し説明します。



関数スキャンは非常に単純なアセンブリです。 レコードセットを返す関数を実行し、それだけです。 「lower（）」のような関数は実行しませんが、多くの行または列を返す可能性がある関数のみを実行します。関数が行を返すと、それらはプランツリーのFunction Scanより1レベル高いノードまたはクライアントに転送されますFunction Scanがルートノードの場合。



ここで発生する可能性がある唯一の追加ロジックは、次のように、受信した回線をフィルタリングする機能です。

 $ explain analyze select * from generate_Series(1,10) i where i < 3; QUERY PLAN ------------------------------------------------------------------------------------------------------------------- Function Scan on generate_series i (cost=0.00..12.50 rows=333 width=4) (actual time=0.012..0.014 rows=2 loops=1) Filter: (i < 3) Rows Removed by Filter: 8 Total runtime: 0.030 ms (4 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

並べ替え

これは非常に理解しやすいと思います-ソートは選択したレコードを取得し、特定の方法でソートして返します。



例：

 $ explain analyze select * from pg_class order by relname; QUERY PLAN --------------------------------------------------------------------------------------------------------------- Sort (cost=22.88..23.61 rows=292 width=203) (actual time=0.230..0.253 rows=295 loops=1) Sort Key: relname Sort Method: quicksort Memory: 103kB -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=203) (actual time=0.007..0.048 rows=295 loops=1) Total runtime: 0.326 ms (5 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単ですが、興味深いロジックが潜んでいます。 まず、ソートに必要なメモリがwork_memの値よりも大きい場合、ディスクソートへの切り替えが発生します。

 $ explain analyze select random() as x from generate_series(1,14000) i order by x; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------ Sort (cost=62.33..64.83 rows=1000 width=0) (actual time=16.713..18.090 rows=14000 loops=1) Sort Key: (random()) Sort Method: quicksort Memory: 998kB -> Function Scan on generate_series i (cost=0.00..12.50 rows=1000 width=0) (actual time=2.036..4.533 rows=14000 loops=1) Total runtime: 18.942 ms (5 rows) $ explain analyze select random() as x from generate_series(1,15000) i order by x; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------ Sort (cost=62.33..64.83 rows=1000 width=0) (actual time=27.052..28.780 rows=15000 loops=1) Sort Key: (random()) Sort Method: external merge Disk: 264kB -> Function Scan on generate_series i (cost=0.00..12.50 rows=1000 width=0) (actual time=2.171..4.894 rows=15000 loops=1) Total runtime: 29.767 ms (5 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例のソート方法の変更に注目してください。



そのような場合、Postgresは$ PGDATA / base / pgsql_tmp /ディレクトリに保存されている一時ファイルを使用します。 もちろん、それらの必要性がなくなるとすぐに削除されます。



別の追加のプロパティは、次のように、Limit操作によって呼び出された場合、Sortが作業メソッドを変更できることです。

 $ explain analyze select * from pg_class order by relfilenode limit 5; QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Limit (cost=15.77..15.78 rows=5 width=203) (actual time=0.119..0.120 rows=5 loops=1) -> Sort (cost=15.77..16.50 rows=292 width=203) (actual time=0.118..0.118 rows=5 loops=1) Sort Key: relfilenode Sort Method: top-N heapsort Memory: 26kB -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=203) (actual time=0.005..0.047 rows=295 loops=1) Total runtime: 0.161 ms (6 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、選択したデータセットを並べ替えるには、データセット全体を処理する必要があります。 しかし、Postgresは、必要な行数が少ない場合、データセット全体を並べ替える必要はなく、最初の値のみを取得すれば十分であることを知っています。



Big O表記では、一般的な並べ替えには複雑度O（m * log（m））がありますが、Top-Nには複雑度O（m * log（n））があります。ここで、mはテーブル内の行数、nは返される行数です。 この並べ替え方法は、使用するメモリがはるかに少ないことを知っておくことが重要です（最終的に、並べ替えられた行からデータセット全体を収集する必要はなく、数行あれば十分です）。したがって、一時ファイルに低速のディスクを使用する可能性は低くなります。

制限

limitは非常に単純なので繰り返し使用しましたが、それでも詳細に説明します。 制限操作はサブ操作を開始し、サブ操作が返した最初のN行のみを返します。 通常、この後、サブオペレーションは停止しますが、場合によっては（たとえば、pl / PgSQL関数の呼び出し）、サブオペレーションは最初の行を返すまでに作業をすでに完了しています。



簡単な例：

 $ explain analyze select * from pg_class; QUERY PLAN --------------------------------------------------------------------------------------------------------- Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=203) (actual time=0.008..0.047 rows=295 loops=1) Total runtime: 0.096 ms (2 rows) $ explain analyze select * from pg_class limit 2; QUERY PLAN ------------------------------------------------------------------------------------------------------------- Limit (cost=0.00..0.07 rows=2 width=203) (actual time=0.009..0.010 rows=2 loops=1) -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=203) (actual time=0.008..0.009 rows=2 loops=1) Total runtime: 0.045 ms (3 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、2番目のケースで制限を使用すると、ネストされたSeqスキャン操作が2行を検出した直後にその作業を完了したという事実に至りました。

ハッシュ集計

この操作は主に、GROUP BYおよびsum（）、avg（）、min（）、max（）などの一部の集計を使用する場合に使用されます。



例：

 $ explain analyze select relkind, count(*) from pg_Class group by relkind; QUERY PLAN ------------------------------------------------------------------------------------------------------------- HashAggregate (cost=12.38..12.42 rows=4 width=1) (actual time=0.223..0.224 rows=5 loops=1) -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=1) (actual time=0.008..0.053 rows=295 loops=1) Total runtime: 0.273 ms (3 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HashAggregateは次を実行します。受信する各行に対して、GROUP BY“キー”（この場合はrelkind）を見つけます。 次に、ハッシュ（連想配列、辞書）で、このキーが示すバスケットに選択した行を配置します。



すべての行が処理された後、ハッシュをスキャンし、キー値ごとに1行を返し、必要に応じて適切な計算（合計、最小、平均など）を行います。



HashAggregateは、少なくとも1行を返す前にすべての行をスキャンする必要があることを理解することが重要です。



これを理解している場合、潜在的な問題が発生している可能性があります。数百万行ある状況で何をすべきか。 ハッシュは大きすぎてメモリに収まりません。 そして、ここで再びwork_memを使用します 。 生成されたハッシュが大きすぎる場合、ディスクにマージされます（再び$ PGDATA / base / pgsql_tmpにあります）。



これは、プランにHashAggregateとSortの両方がある場合、最大2 * work_memを使用できることを意味します。 このような計画は簡単に入手できます。

 $ explain analyze select relkind, count(*) from pg_Class group by relkind order by relkind; QUERY PLAN ------------------------------------------------------------------------------------------------------------------- Sort (cost=12.46..12.47 rows=4 width=1) (actual time=0.260..0.261 rows=5 loops=1) Sort Key: relkind Sort Method: quicksort Memory: 25kB -> HashAggregate (cost=12.38..12.42 rows=4 width=1) (actual time=0.221..0.222 rows=5 loops=1) -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=1) (actual time=0.006..0.044 rows=295 loops=1) Total runtime: 0.312 ms (6 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、work_memは操作に対する制約であるため、1つの要求でwork_memを何度も使用できます。 したがって、リクエストが1000個のHashAggregatesとSorts（およびwork_memを使用する他の操作）を使用する場合、合計メモリ消費量が非常に大きくなる可能性があります。

ハッシュ結合/ハッシュ

HashAggregateについて説明したばかりなので、Hash Joinに進むのが論理的です。



この操作には、前の操作とは異なり、 2つのサブ操作があります。 それらの1つは常に「ハッシュ」で、2つ目は別のものです。



名前が示すように、ハッシュ結合は2セットのレコードを結合するために使用されます。 たとえば、次のように：

 $ explain analyze select * from pg_class c join pg_namespace n on c.relnamespace = n.oid; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Hash Join (cost=1.14..16.07 rows=292 width=316) (actual time=0.036..0.343 rows=295 loops=1) Hash Cond: (c.relnamespace = n.oid) -> Seq Scan on pg_class c (cost=0.00..10.92 rows=292 width=203) (actual time=0.007..0.044 rows=295 loops=1) -> Hash (cost=1.06..1.06 rows=6 width=117) (actual time=0.012..0.012 rows=6 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on pg_namespace n (cost=0.00..1.06 rows=6 width=117) (actual time=0.004..0.005 rows=6 loops=1) Total runtime: 0.462 ms (7 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは次のように機能します：最初に、Hash Joinが「Hash」を呼び出し、次に別の何か（この場合はpg_namespaceによるSeq Scan）を呼び出します。次に、Hashはハッシュをメモリ内（またはサイズに応じてディスク上）に作成します/データを結合するために使用されるものを使用してハッシュ化されたソースからの文字列を持つ連想配列/辞書（この場合、これはpg_namespaceのOID列です）。



もちろん、指定された結合キーに対して多くの行を持つことができます（主キーと結合しているため、この場合はそうではありませんが、一般的には、1つのハッシュキーに対して多くの行があるでしょう）。



Perl表記では、ハッシュ出力は次のようになります。

 { '123' => [ { data for row with OID = 123 }, ], '256' => [ { data for row with OID = 256 }, ], ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Hash Joinは2番目のサブオペレーション（この場合はpg_classによるシーケンススキャン）を開始し、そこからの各行に対して次のことを行います。

1. 結合キー（この場合はpg_class.relnamespace）がハッシュ操作によって返されるハッシュにあるかどうかを確認します。
2. そうでない場合、サブオペレーションのこの行は無視されます（返されません）。
3. キーが存在する場合、ハッシュ結合はハッシュから行を取得し、この行に基づいて一方で、すべてのハッシュ行で行出力を生成します。

結合の両側が一度だけ実行されることに注意することが重要です（この場合、両方ともseqスキャンです）、最初に、ハッシュ操作によって呼び出されたものはハッシュに格納されたすべての行を返し、2番目は行ごとに処理されます、ファーストパーティハッシュに存在しない行はスキップされます（ハッシュが豊富であるにもかかわらず、この文が明確であることを願っています）。



両方のサブスキャンは任意のタイプの操作である可能性があるため、フィルター、インデックススキャン、または想像できるあらゆるものになる可能性があります。



Hash Join / Hashに関して最後に言及する価値があるのは、Hash操作は、SortやHashAggregateと同様に、work_memまでのメモリを使用することです。

ハッシュ結合/ハッシュ

組合について話しているので、ネストループについて議論する価値があります。 例：

 $ explain analyze select a.* from pg_class c join pg_attribute a on c.oid = a.attrelid where c.relname in ( 'pg_class', 'pg_namespace' ); QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------- Nested Loop (cost=0.28..52.32 rows=16 width=203) (actual time=0.057..0.134 rows=46 loops=1) -> Seq Scan on pg_class c (cost=0.00..11.65 rows=2 width=4) (actual time=0.043..0.080 rows=2 loops=1) Filter: (relname = ANY ('{pg_class,pg_namespace}'::name[])) Rows Removed by Filter: 291 -> Index Scan using pg_attribute_relid_attnum_index on pg_attribute a (cost=0.28..20.25 rows=8 width=203) (actual time=0.007..0.015 rows=23 loops=2) Index Cond: (attrelid = c.oid) Total runtime: 0.182 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、選択した操作を複数回実行できるため、非常に興味深い計画です。



ハッシュ結合と同様に、ネストされたループには2つの「子孫」があります。 まず、「Seq Scan」を起動し（この例では最初に最初のノードを起動します）、次に返された各行（この例では2行のみ）で2番目の操作を開始します（この例ではpg_attributeによるインデックススキャン）。



インデックススキャンの実際のメタ情報に「ループ= 2」があることに気づいたかもしれません。つまり、この操作は2回実行され、他の値（行、時間）はすべての実行の平均値です。



Explain.depesz.comから次の計画を見てみましょう。 カテゴリのすべてのインデックススキャン操作の実際の実行時間は0.002〜0.003ミリ秒であることに注意してください。 ただし、このインデックススキャンは26k回以上実行されたため、このノードで費やされた合計時間は78.852msです。



したがって、処理は次のようになります。

1. ネストされたループは、ユニオンの最初のサイドを一度起動します。 彼女を「A」と呼びましょう。
2. 「A」からの各行について、2番目の操作が開始されます（「B」と呼びましょう）。
3. 「B」が単一の行を返さなかった場合、「A」からのデータは無視されます。
4. 「B」が行を返した場合、返された行ごとに、ネストされたループはAおよびBの現在の行に基づいて新しい行を返します。

結合を結合

別のデータマージ方法は、マージ結合と呼ばれます。 結合キーを使用して結合可能なデータセットが並べ替えられる（または低コストで並べ替えられる）場合に使用されます。



既製の視覚的な例はないので、結合する前にデータをソートするサブクエリを使用して人為的に作成します。

 $ explain analyze select * from ( select oid, * from pg_class order by oid) as c join ( select * from pg_attribute a order by attrelid) as a on c.oid = a.attrelid; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Merge Join (cost=23.16..268.01 rows=2273 width=410) (actual time=0.658..3.779 rows=2274 loops=1) Merge Cond: (pg_class.oid = a.attrelid) -> Sort (cost=22.88..23.61 rows=292 width=207) (actual time=0.624..0.655 rows=293 loops=1) Sort Key: pg_class.oid Sort Method: quicksort Memory: 102kB -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=207) (actual time=0.011..0.211 rows=293 loops=1) -> Materialize (cost=0.28..212.34 rows=2273 width=203) (actual time=0.028..1.264 rows=2274 loops=1) -> Index Scan using pg_attribute_relid_attnum_index on pg_attribute a (cost=0.28..183.92 rows=2273 width=203) (actual time=0.015..0.752 rows=2274 loops=1) Total runtime: 4.009 ms (9 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マージ結合は、他のユニオンと同様に、2つのサブオペレーション（この場合はソートとマテリアライズ）を実行します。 どちらも並べ替えられたデータを返し、並べ替え順序は結合操作の場合と同じなので、Pgはサブ操作によって返された両方のデータセットをスキャンし、同時に識別子が一致するかどうかを確認できます。



手順は次のとおりです。

• 右側の結合列が左側の結合列と同じ場合：
  
  
  • 左右の現在の行に基づいて、新しい連結行を返します。
  • 次の行を右（または右に行がもうない場合は左）に移動します。
  • ステップ1に戻ります。
• 右側の結合列が左側の結合列よりも「小さい」場合：
  
  
  • 次の行を右側に移動します（もう行がない場合は、処理を終了します）。
  • ステップ1に戻ります。
• 右側の結合列が左側の結合列よりも「大きい」場合：
  
  
  • 左側の次の行を取得します（行がもうない場合は、処理を終了します）。
  • 手順1に戻ります。

これは、データセットを結合する非常に便利な方法ですが、ソートされたソースに対してのみ機能します。 現在のExplain.depesz.comデータベースに基づいて、以下があります。

• 操作「ネストされたループ」を含む44,721の計画。
• 「ハッシュ結合」を使用した34,305プラン。
• Merge Joinを使用した合計8,889の計画。

ハッシュ結合/ネストされたループ/結合結合修飾子

上記のすべての例で、結合の両側から文字列を受け取った場合にのみ、結合操作が文字列を返すことを示しました。



しかし、これは常に起こるとは限りません。 左、右、完全（LEFT / RIGHT / FULL OUTER JOIN）外部アソシエーションと、いわゆるアンチ結合を使用できます。



左/右結合の場合、操作の名前は次のように変更されます。

• ハッシュ左結合、
• ハッシュ右結合、
• 左結合のマージ、
• 右結合をマージ、
• ネストされたループの左結合。

ネストされたループの右結合は存在しません。ネストされたループは常に左側から始まり、ループの基礎として左側を使用するためです。 したがって、ネストされたループで機能する右結合を使用する共用体は、ネストされたループ操作が機能するように内部的に左結合に変換されます。



これらのすべての場合において、論理は単純です：組合の2つの側面-左と右があります。 そして、その側がユニオンで言及されると、 反対側に対応する行がない場合でも、新しい行を返します。



これは、次のようなクエリで発生します。

 select * from a left join b on ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（または右結合）。



ハッシュ結合/結合の結合とネストされたループに関するその他の情報はすべて同じで、ライン出力が生成されるタイミングのロジックにわずかな変更のみがあります。



次の操作名を持つ完全結合と呼ばれるバージョンもあります。

• ハッシュ完全結合、
• 完全結合をマージします。

この場合、どちらかの側にデータがあるかどうかに関係なく、ユニオンは新しい行出力を生成します（データが少なくとも片側にある限り）。 これは次の場合に発生します。

 select * from a full join b ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前の例のように、すべての処理が発生します。



さらに、いわゆるアンチ結合があります。 操作の名前は次のとおりです。

• ハッシュアンチ結合、
• アンチ結合のマージ、
• ネストループアンチ結合。

これらの場合、Joinは、右側で単一の文字列が見つからない場合にのみ文字列を返します。 これは、「WHERE not exists（）」または「left join ... where right_table.column is null」などの操作を行う場合に役立ちます。



この例のように：

 $ explain analyze select * from pg_class c where not exists (select * from pg_attribute a where a.attrelid = c.oid and a.attnum = 10); QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hash Anti Join (cost=62.27..78.66 rows=250 width=203) (actual time=0.145..0.448 rows=251 loops=1) Hash Cond: (c.oid = a.attrelid) -> Seq Scan on pg_class c (cost=0.00..10.92 rows=292 width=207) (actual time=0.009..0.195 rows=293 loops=1) -> Hash (cost=61.75..61.75 rows=42 width=4) (actual time=0.123..0.123 rows=42 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 2kB -> Index Only Scan using pg_attribute_relid_attnum_index on pg_attribute a (cost=0.28..61.75 rows=42 width=4) (actual time=0.021..0.109 rows=42 loops=1) Index Cond: (attnum = 10) Heap Fetches: 0 Total runtime: 0.521 ms (9 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、Pgは右側（pg_attributeによるインデックススキャン）を実行し、ハッシュしてから左側（pg_classによるSeqスキャン）を実行し、指定されたpg_class.oidのHashにエントリがなかった行のみを返しました。

マテリアライズ

この操作は、結合結合の例ですでに実証されていますが、他の場合に役立つ場合があります。



Psqlには多くの内部コマンドがあります。 それらの1つは\ dTSで、すべてのシステムデータタイプをリストします。 内部的に、\ dTSはこのリクエストを実行します：

 SELECT n.nspname as "Schema", pg_catalog.format_type(t.oid, NULL) AS "Name", pg_catalog.obj_description(t.oid, 'pg_type') as "Description" FROM pg_catalog.pg_type t LEFT JOIN pg_catalog.pg_namespace n ON n.oid = t.typnamespace WHERE (t.typrelid = 0 OR (SELECT c.relkind = 'c' FROM pg_catalog.pg_class c WHERE c.oid = t.typrelid)) AND NOT EXISTS(SELECT 1 FROM pg_catalog.pg_type el WHERE el.oid = t.typelem AND el.typarray = t.oid) AND pg_catalog.pg_type_is_visible(t.oid) ORDER BY 1, 2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼の計画はこれです：

  QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------- Sort (cost=2783.00..2783.16 rows=65 width=68) (actual time=3.883..3.888 rows=87 loops=1) Sort Key: n.nspname, (format_type(t.oid, NULL::integer)) Sort Method: quicksort Memory: 39kB -> Nested Loop Left Join (cost=16.32..2781.04 rows=65 width=68) (actual time=0.601..3.657 rows=87 loops=1) Join Filter: (n.oid = t.typnamespace) Rows Removed by Join Filter: 435 -> Hash Anti Join (cost=16.32..2757.70 rows=65 width=8) (actual time=0.264..0.981 rows=87 loops=1) Hash Cond: ((t.typelem = el.oid) AND (t.oid = el.typarray)) -> Seq Scan on pg_type t (cost=0.00..2740.26 rows=81 width=12) (actual time=0.012..0.662 rows=157 loops=1) Filter: (pg_type_is_visible(oid) AND ((typrelid = 0::oid) OR (SubPlan 1))) Rows Removed by Filter: 185 SubPlan 1 -> Index Scan using pg_class_oid_index on pg_class c (cost=0.15..8.17 rows=1 width=1) (actual time=0.002..0.002 rows=1 loops=98) Index Cond: (oid = t.typrelid) -> Hash (cost=11.33..11.33 rows=333 width=8) (actual time=0.241..0.241 rows=342 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 14kB -> Seq Scan on pg_type el (cost=0.00..11.33 rows=333 width=8) (actual time=0.002..0.130 rows=342 loops=1) -> Materialize (cost=0.00..1.09 rows=6 width=68) (actual time=0.000..0.001 rows=6 loops=87) -> Seq Scan on pg_namespace n (cost=0.00..1.06 rows=6 width=68) (actual time=0.002..0.003 rows=6 loops=1) Total runtime: 3.959 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見やすくするために、このプランもExplain.depesz.comにアップロードしました 。



操作＃9はマテリアライズであることに注意してください。 なんで？



マテリアライズはネストされたループの左結合-操作＃2によって呼び出されます。 ネストされたループにより、選択された操作が強制的に複数回、この場合は87回実行されます。



ユニオンの右側は、pg_namespaceによるSeq Scanです。 そのため、理論的には、Postgresはpg_namespaceのシーケンシャルスキャンを87回実行する必要があります。 このテーブルの1回の順次スキャンに0.003ミリ秒かかることを考慮すると、合計時間は約0.25ミリ秒になると予想できます。



しかし、Postgresはよりスマートになっています。 彼は、テーブルを1回スキャンして、すべての行のイメージをメモリに構築する方がコストが低いことを理解しています。 次に、テーブルをスキャンする必要がない場合は、可視性情報を確認し、データページを解析します。 単にメモリからデータを取得します。



これにより、すべての合計時間（テーブルを1回読み取り、メモリにデータイメージを準備し、このイメージを87回スキャンする）は0.087msでした。



あなたは言うことができます：「しかし、なぜ結合は以前にマテリアライズを使用したのですか、それはたった1回のスキャンを実行したのですか？」計画を思い出しましょう：

 $ explain analyze select * from ( select oid, * from pg_class order by oid) as c join ( select * from pg_attribute a order by attrelid) as a on c.oid = a.attrelid; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Merge Join (cost=23.16..268.01 rows=2273 width=410) (actual time=0.658..3.779 rows=2274 loops=1) Merge Cond: (pg_class.oid = a.attrelid) -> Sort (cost=22.88..23.61 rows=292 width=207) (actual time=0.624..0.655 rows=293 loops=1) Sort Key: pg_class.oid Sort Method: quicksort Memory: 102kB -> Seq Scan on pg_class (cost=0.00..10.92 rows=292 width=207) (actual time=0.011..0.211 rows=293 loops=1) -> Materialize (cost=0.28..212.34 rows=2273 width=203) (actual time=0.028..1.264 rows=2274 loops=1) -> Index Scan using pg_attribute_relid_attnum_index on pg_attribute a (cost=0.28..183.92 rows=2273 width=203) (actual time=0.015..0.752 rows=2274 loops=1) Total runtime: 4.009 ms (9 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, . , Merge Join . ( ), , ( ).



- Materialize , ( Index Scan), , .



, Materialize ( ), , , .



今日は以上です。私はこれを終了すると思ったが、説明する価値のある操作がさらにたくさんあるので、このシリーズでは少なくとも2つの投稿（残りの操作と統計情報）があります。