クエリが論理的に類似している場合、なぜプランが異なるのですか？
7週間で7つのデータベース から、3日目の最初の宿題の質問に答えるために2つの関数を書きました。
好きな映画のタイトルや俳優の名前を入力できるストアドプロシージャを作成すると、俳優が主演した映画または類似のジャンルの映画に基づいて上位5つの提案が返されます。
私の最初の試みは正しいが遅い。結果が返されるまでに最大2000msかかる場合があります。
CREATE OR REPLACE FUNCTION suggest_movies(IN query text, IN result_limit integer DEFAULT 5)
RETURNS TABLE(movie_id integer, title text) AS
$BODY$
WITH suggestions AS (
SELECT
actors.name AS entity_term,
movies.movie_id AS suggestion_id,
movies.title AS suggestion_title,
1 AS rank
FROM actors
INNER JOIN movies_actors ON (actors.actor_id = movies_actors.actor_id)
INNER JOIN movies ON (movies.movie_id = movies_actors.movie_id)
UNION ALL
SELECT
searches.title AS entity_term,
suggestions.movie_id AS suggestion_id,
suggestions.title AS suggestion_title,
RANK() OVER (PARTITION BY searches.movie_id ORDER BY cube_distance(searches.genre, suggestions.genre)) AS rank
FROM movies AS searches
INNER JOIN movies AS suggestions ON
(searches.movie_id <> suggestions.movie_id) AND
(cube_enlarge(searches.genre, 2, 18) @> suggestions.genre)
)
SELECT suggestion_id, suggestion_title
FROM suggestions
WHERE entity_term = query
ORDER BY rank, suggestion_id
LIMIT result_limit;
$BODY$
LANGUAGE sql;
私の2番目の試みは正しく、高速です。フィルターをCTEからユニオンの各部分に押し込むことで最適化しました。
この行を外部クエリから削除しました。
WHERE entity_term = query
次の行を最初の内部クエリに追加しました。
WHERE actors.name = query
この行を2番目の内部クエリに追加しました。
WHERE movies.title = query
2番目の関数は、同じ結果を返すのに約10msかかります。
データベースには、関数の定義以外は何も変わりません。
なぜPostgreSQLはこれらの2つの論理的に同等なクエリに対してこのような異なるプランを生成するのですか？
EXPLAIN ANALYZE最初の関数の計画は次のようになります。
Limit (cost=7774.18..7774.19 rows=5 width=44) (actual time=1738.566..1738.567 rows=5 loops=1)
CTE suggestions
-> Append (cost=332.56..7337.19 rows=19350 width=285) (actual time=7.113..1577.823 rows=383024 loops=1)
-> Subquery Scan on "*SELECT* 1" (cost=332.56..996.80 rows=11168 width=33) (actual time=7.113..22.258 rows=11168 loops=1)
-> Hash Join (cost=332.56..885.12 rows=11168 width=33) (actual time=7.110..19.850 rows=11168 loops=1)
Hash Cond: (movies_actors.movie_id = movies.movie_id)
-> Hash Join (cost=143.19..514.27 rows=11168 width=18) (actual time=4.326..11.938 rows=11168 loops=1)
Hash Cond: (movies_actors.actor_id = actors.actor_id)
-> Seq Scan on movies_actors (cost=0.00..161.68 rows=11168 width=8) (actual time=0.013..1.648 rows=11168 loops=1)
-> Hash (cost=80.86..80.86 rows=4986 width=18) (actual time=4.296..4.296 rows=4986 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 252kB
-> Seq Scan on actors (cost=0.00..80.86 rows=4986 width=18) (actual time=0.009..1.681 rows=4986 loops=1)
-> Hash (cost=153.61..153.61 rows=2861 width=19) (actual time=2.768..2.768 rows=2861 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 146kB
-> Seq Scan on movies (cost=0.00..153.61 rows=2861 width=19) (actual time=0.003..1.197 rows=2861 loops=1)
-> Subquery Scan on "*SELECT* 2" (cost=6074.48..6340.40 rows=8182 width=630) (actual time=1231.324..1528.188 rows=371856 loops=1)
-> WindowAgg (cost=6074.48..6258.58 rows=8182 width=630) (actual time=1231.324..1492.106 rows=371856 loops=1)
-> Sort (cost=6074.48..6094.94 rows=8182 width=630) (actual time=1231.307..1282.550 rows=371856 loops=1)
Sort Key: searches.movie_id, (cube_distance(searches.genre, suggestions_1.genre))
Sort Method: external sort Disk: 21584kB
-> Nested Loop (cost=0.27..3246.72 rows=8182 width=630) (actual time=0.047..909.096 rows=371856 loops=1)
-> Seq Scan on movies searches (cost=0.00..153.61 rows=2861 width=315) (actual time=0.003..0.676 rows=2861 loops=1)
-> Index Scan using movies_genres_cube on movies suggestions_1 (cost=0.27..1.05 rows=3 width=315) (actual time=0.016..0.277 rows=130 loops=2861)
Index Cond: (cube_enlarge(searches.genre, 2::double precision, 18) @> genre)
Filter: (searches.movie_id <> movie_id)
Rows Removed by Filter: 1
-> Sort (cost=436.99..437.23 rows=97 width=44) (actual time=1738.565..1738.566 rows=5 loops=1)
Sort Key: suggestions.rank, suggestions.suggestion_id
Sort Method: top-N heapsort Memory: 25kB
-> CTE Scan on suggestions (cost=0.00..435.38 rows=97 width=44) (actual time=1281.905..1738.531 rows=43 loops=1)
Filter: (entity_term = 'Die Hard'::text)
Rows Removed by Filter: 382981
Total runtime: 1746.623 ms
EXPLAIN ANALYZE 2番目のクエリのプランは次のようになります。
Limit (cost=43.74..43.76 rows=5 width=44) (actual time=1.231..1.234 rows=5 loops=1)
CTE suggestions
-> Append (cost=4.86..43.58 rows=5 width=391) (actual time=1.029..1.141 rows=43 loops=1)
-> Subquery Scan on "*SELECT* 1" (cost=4.86..20.18 rows=2 width=33) (actual time=0.047..0.047 rows=0 loops=1)
-> Nested Loop (cost=4.86..20.16 rows=2 width=33) (actual time=0.047..0.047 rows=0 loops=1)
-> Nested Loop (cost=4.58..19.45 rows=2 width=18) (actual time=0.045..0.045 rows=0 loops=1)
-> Index Scan using actors_name on actors (cost=0.28..8.30 rows=1 width=18) (actual time=0.045..0.045 rows=0 loops=1)
Index Cond: (name = 'Die Hard'::text)
-> Bitmap Heap Scan on movies_actors (cost=4.30..11.13 rows=2 width=8) (never executed)
Recheck Cond: (actor_id = actors.actor_id)
-> Bitmap Index Scan on movies_actors_actor_id (cost=0.00..4.30 rows=2 width=0) (never executed)
Index Cond: (actor_id = actors.actor_id)
-> Index Scan using movies_pkey on movies (cost=0.28..0.35 rows=1 width=19) (never executed)
Index Cond: (movie_id = movies_actors.movie_id)
-> Subquery Scan on "*SELECT* 2" (cost=23.31..23.40 rows=3 width=630) (actual time=0.982..1.081 rows=43 loops=1)
-> WindowAgg (cost=23.31..23.37 rows=3 width=630) (actual time=0.982..1.064 rows=43 loops=1)
-> Sort (cost=23.31..23.31 rows=3 width=630) (actual time=0.963..0.971 rows=43 loops=1)
Sort Key: searches.movie_id, (cube_distance(searches.genre, suggestions_1.genre))
Sort Method: quicksort Memory: 28kB
-> Nested Loop (cost=4.58..23.28 rows=3 width=630) (actual time=0.808..0.916 rows=43 loops=1)
-> Index Scan using movies_title on movies searches (cost=0.28..8.30 rows=1 width=315) (actual time=0.025..0.027 rows=1 loops=1)
Index Cond: (title = 'Die Hard'::text)
-> Bitmap Heap Scan on movies suggestions_1 (cost=4.30..14.95 rows=3 width=315) (actual time=0.775..0.844 rows=43 loops=1)
Recheck Cond: (cube_enlarge(searches.genre, 2::double precision, 18) @> genre)
Filter: (searches.movie_id <> movie_id)
Rows Removed by Filter: 1
-> Bitmap Index Scan on movies_genres_cube (cost=0.00..4.29 rows=3 width=0) (actual time=0.750..0.750 rows=44 loops=1)
Index Cond: (cube_enlarge(searches.genre, 2::double precision, 18) @> genre)
-> Sort (cost=0.16..0.17 rows=5 width=44) (actual time=1.230..1.231 rows=5 loops=1)
Sort Key: suggestions.rank, suggestions.suggestion_id
Sort Method: top-N heapsort Memory: 25kB
-> CTE Scan on suggestions (cost=0.00..0.10 rows=5 width=44) (actual time=1.034..1.187 rows=43 loops=1)
Total runtime: 1.410 ms
CTEの自動述語プッシュダウンはありません
PostgreSQL 9.3はCTEの 述語プッシュダウン を行いません。
述語のプッシュダウンを行うオプティマイザは、where句を内部クエリに移動できます。目標は、関係のないデータをできるだけ早期に除外することです。新しいクエリが論理的に同等である限り、エンジンは関連するすべてのデータをフェッチするため、正しい結果をより迅速に生成します。
コア開発者のトムレーンは、 pgsql-performanceメーリングリスト で論理的同等性を判断するのが難しいことをほのめかしています。
CTEも最適化フェンスとして扱われます。これは、CTEに書き込み可能なクエリが含まれている場合でもセマンティクスを正常に保つためのオプティマイザの制限ではありません。
オプティマイザは読み取り専用のCTEと書き込み可能なCTEを区別しないため、計画を検討する場合は非常に保守的です。 「フェンス」の処理により、オプティマイザがCTE内のwhere句を移動するのを防ぎますが、安全であることは確認できます。
PostgreSQLチームがCTE最適化を改善するのを待つことができますが、今のところ良いパフォーマンスを得るには、書き込みスタイルを変更する必要があります。
パフォーマンスのために書き直す
質問はすでにより良い計画を得るための1つの方法を示しています。フィルター条件を複製すると、基本的に述語プッシュダウンの効果がハードコードされます。
どちらの計画でも、エンジンは結果行を作業テーブルにコピーして、それらをソートできるようにします。作業テーブルが大きいほど、クエリは遅くなります。
最初の計画では、ベーステーブルのすべての行をワークテーブルにコピーし、それをスキャンして結果を見つけます。物事をさらに遅くするには、エンジンにはインデックスがないため、ワークテーブル全体をスキャンする必要があります。
これは、とんでもない不必要な作業です。ベーステーブル内の推定19350行から一致する推定行が5行しかない場合、ベーステーブル内のすべてのデータを2回読み取り、答えを見つけます。
2番目の計画では、インデックスを使用して一致する行を検索し、それらのみを作業テーブルにコピーします。インデックスはデータを効果的にフィルタリングしました。
The Art of SQLの 85ページ で、StéphaneFaroultはユーザーの期待を思い出させます。
エンドユーザーは、予想される行数に忍耐力を調整します。1本の針を要求するとき、干し草の山のサイズにはほとんど注意を払いません。
2番目の計画は針に合わせて調整されるため、ユーザーを満足させ続ける可能性が高くなります。
保守性のために書き直す
1つのフィルターのepxressionを変更して他のフィルターを変更しないと欠陥が発生する可能性があるため、新しいクエリの維持はより困難です。
すべてを一度だけ書いて、それでも優れたパフォーマンスが得られたら、すばらしいと思いませんか？
私たちはできる。オプティマイザはサブクエリの述語プッシュダウンを行います。
単純な例は説明が簡単です。
CREATE TABLE a (c INT);
CREATE TABLE b (c INT);
CREATE INDEX a_c ON a(c);
CREATE INDEX b_c ON b(c);
INSERT INTO a SELECT 1 FROM generate_series(1, 1000000);
INSERT INTO b SELECT 2 FROM a;
INSERT INTO a SELECT 3;
これにより、それぞれインデックス付きの列を持つ2つのテーブルが作成されます。一緒に彼らは百万を含んでいます1s、100万2s、および1つの3。
あなたは針を見つけることができます3これらのクエリのいずれかを使用します。
-- CTE
EXPLAIN ANALYZE
WITH cte AS (
SELECT c FROM a
UNION ALL
SELECT c FROM b
)
SELECT c FROM cte WHERE c = 3;
-- Subquery
EXPLAIN ANALYZE
SELECT c
FROM (
SELECT c FROM a
UNION ALL
SELECT c FROM b
) AS subquery
WHERE c = 3;
CTEの計画は遅い。エンジンは3つのテーブルをスキャンし、約400万行を読み取ります。約1000ミリ秒かかります。
CTE Scan on cte (cost=33275.00..78275.00 rows=10000 width=4) (actual time=471.412..943.225 rows=1 loops=1)
Filter: (c = 3)
Rows Removed by Filter: 2000000
CTE cte
-> Append (cost=0.00..33275.00 rows=2000000 width=4) (actual time=0.011..409.573 rows=2000001 loops=1)
-> Seq Scan on a (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.010..114.869 rows=1000001 loops=1)
-> Seq Scan on b (cost=0.00..18850.00 rows=1000000 width=4) (actual time=5.530..104.674 rows=1000000 loops=1)
Total runtime: 948.594 ms
サブクエリの計画は高速です。エンジンは各インデックスをシークするだけです。ミリ秒もかかりません。
Append (cost=0.42..8.88 rows=2 width=4) (actual time=0.021..0.038 rows=1 loops=1)
-> Index Only Scan using a_c on a (cost=0.42..4.44 rows=1 width=4) (actual time=0.020..0.021 rows=1 loops=1)
Index Cond: (c = 3)
Heap Fetches: 1
-> Index Only Scan using b_c on b (cost=0.42..4.44 rows=1 width=4) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: (c = 3)
Heap Fetches: 0
Total runtime: 0.065 ms
インタラクティブバージョンについては、 SQLFiddle を参照してください。
計画はPostgres 12でも同じです
Postgres 9.3について質問されました。 5年後、そのバージョンは廃止されましたが、何が変更されましたか？
PostgreSQL 12 は、このようなCTEをインライン化します。
インライン化されたWITHクエリ（共通テーブル式）
共通テーブル式（別名
WITHクエリ）は、a）再帰的ではなく、b）副作用がなく、c）の後半で一度だけ参照される場合、クエリ内で自動的にインライン化できるようになりました。クエリ。これにより、PostgreSQL 8.4にWITH句が導入されてから存在していた「最適化フェンス」が削除されます。必要に応じて、MATERIALIZED句を使用して強制的にWITHクエリを具体化できます。
WITH c AS MATERIALIZED ( SELECT * FROM a WHERE a.x % 4 = 0 ) SELECT * FROM c JOIN d ON d.y = a.x;