サブクエリを追加するとPostgreSQLクエリが非常に遅くなる

150万行のテーブルに対する比較的単純なクエリがあります。

SELECT mtid FROM publication
WHERE mtid IN (9762715) OR last_modifier=21321
LIMIT 5000;

EXPLAIN ANALYZE 出力：

Limit  (cost=8.84..12.86 rows=1 width=8) (actual time=0.985..0.986 rows=1 loops=1)
  ->  Bitmap Heap Scan on publication  (cost=8.84..12.86 rows=1 width=8) (actual time=0.984..0.985 rows=1 loops=1)
        Recheck Cond: ((mtid = 9762715) OR (last_modifier = 21321))
        ->  BitmapOr  (cost=8.84..8.84 rows=1 width=0) (actual time=0.971..0.971 rows=0 loops=1)
              ->  Bitmap Index Scan on publication_pkey  (cost=0.00..4.42 rows=1 width=0) (actual time=0.295..0.295 rows=1 loops=1)
                    Index Cond: (mtid = 9762715)
              ->  Bitmap Index Scan on publication_last_modifier_btree  (cost=0.00..4.42 rows=1 width=0) (actual time=0.674..0.674 rows=0 loops=1)
                    Index Cond: (last_modifier = 21321)
Total runtime: 1.027 ms

これまでのところ、高速で、使用可能なインデックスを使用しています。
ここで、クエリを少しだけ変更すると、結果は次のようになります。

SELECT mtid FROM publication
WHERE mtid IN (SELECT 9762715) OR last_modifier=21321
LIMIT 5000;

EXPLAIN ANALYZE出力は次のようになります。

Limit  (cost=0.01..2347.74 rows=5000 width=8) (actual time=2735.891..2841.398 rows=1 loops=1)
  ->  Seq Scan on publication  (cost=0.01..349652.84 rows=744661 width=8) (actual time=2735.888..2841.393 rows=1 loops=1)
        Filter: ((hashed SubPlan 1) OR (last_modifier = 21321))
        SubPlan 1
          ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.001..0.001 rows=1 loops=1)
Total runtime: 2841.442 ms

それほど速くなく、seqスキャンを使用しています...

もちろん、アプリケーションによって実行される元のクエリは少し複雑で、さらに遅くなります。もちろん、休止状態で生成された元のクエリはそう(SELECT 9762715)ではありませんが、それでも速度は低下しません(SELECT 9762715)。クエリはhibernateによって生成されるため、それらを変更することは非常に困難であり、一部の機能は使用できません（たとえばUNION、使用できないため、高速になります）。

質問

1. 2番目のケースでインデックスを使用できないのはなぜですか？それらはどのように使用できますか？
2. 他の方法でクエリのパフォーマンスを改善できますか？

追加の考え

最初のケースは手動でSELECTを実行し、結果のリストをクエリに入れることで使用できるようです。IN（）リストに5000の数値があっても、2番目のソリューションより4倍高速です。しかし、それは間違っているように見えます（また、100倍も高速になる可能性があります:)）。クエリプランナーがこれら2つのクエリに対してまったく異なる方法を使用する理由は完全に理解できないため、この問題に対するより良い解決策を見つけたいと思います。

ここで問題の核心が明らかになります。

パブリケーションのシーケンススキャン（コスト= 0.01..349652.84 行= 744661幅= 8）（実際の時間= 2735.888..2841.393 行= 1ループ= 1）

Postgres は 744661行を返すと推定していますが、実際には1行であることが判明しています。Postgresがクエリから何を期待できるかがよくわからない場合、より適切に計画することはできません。実際のクエリが背後に隠れていることを確認する必要があります。(SELECT 9762715)また、おそらくテーブルの定義、制約、カーディナリティ、およびデータの分布についても知っている必要があります。明らかに、Postgresが返す行数を予測することはできません。それは何に応じて、問合せをリライトする方法があるかもしれませんです。

サブクエリが行以上を返すことができないことがわかっている場合はn、次のコマンドを使用してPostgresに通知できます。

SELECT mtid
FROM   publication
WHERE  mtid IN (SELECT ... LIMIT n) --  OR last_modifier=21321
LIMIT  5000;

nが十分に小さい場合、Postgresは（ビットマップ）インデックススキャンに切り替えます。ただし、これは単純な場合にのみ機能します。OR条件を追加すると動作が停止します。現在、クエリプランナーはこれに対応できません。

IN (SELECT ...)そもそもめったに使用しません。通常、同じことを実装するより良い方法があり、多くの場合、EXISTS準結合を使用します。ときどき（LEFT）JOIN（LATERAL）...

明白な回避策はを使用するUNIONことですが、あなたはそれを除外しました。実際のサブクエリやその他の関連する詳細を知らなければ、これ以上言うことはできません。

私の同僚は、クエリを変更して単純な書き換えを必要とし、必要な処理を実行する方法を見つけました。

SELECT mtid FROM publication 
WHERE 
  mtid = ANY( (SELECT ARRAY(SELECT 9762715))::bigint[] )
  OR last_modifier=21321
LIMIT 5000;

説明分析は今です：

 Limit  (cost=92.58..9442.38 rows=2478 width=8) (actual time=0.071..0.074 rows=1 loops=1)
   InitPlan 2 (returns $1)
     ->  Result  (cost=0.01..0.02 rows=1 width=0) (actual time=0.010..0.011 rows=1 loops=1)
           InitPlan 1 (returns $0)
             ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.001..0.002 rows=1 loops=1)
   ->  Bitmap Heap Scan on publication  (cost=92.56..9442.36 rows=2478 width=8) (actual time=0.069..0.070 rows=1 loops=1)
         Recheck Cond: ((mtid = ANY (($1)::bigint[])) OR (last_modifier = 21321))
         Heap Blocks: exact=1
         ->  BitmapOr  (cost=92.56..92.56 rows=2478 width=0) (actual time=0.060..0.060 rows=0 loops=1)
               ->  Bitmap Index Scan on publication_pkey  (cost=0.00..44.38 rows=10 width=0) (actual time=0.046..0.046 rows=1 loops=1)
                     Index Cond: (mtid = ANY (($1)::bigint[]))
               ->  Bitmap Index Scan on publication_last_modifier_btree  (cost=0.00..46.94 rows=2468 width=0) (actual time=0.011..0.011 rows=0 loops=1)
                     Index Cond: (last_modifier = 21321)
 Planning time: 0.704 ms
 Execution time: 0.153 ms

この方法ですべての副選択を見つけて書き換える単純なパーサーを作成し、それをhibernateフックに追加してネイティブクエリを操作できるようです。

2番目の質問への回答：はい、ORDER BYをサブクエリに追加できます。これは、良い影響を与えます。しかし、それはパフォーマンスの「EXISTS（サブクエリ）」ソリューションに似ています。サブクエリの結果が2行になる場合でも、大きな違いがあります。

SELECT mtid FROM publication
WHERE mtid IN (SELECT #column# ORDER BY #column#) OR last_modifier=21321
LIMIT 5000;