하위 쿼리 추가시 PostgreSQL 쿼리 속도가 매우 느림

1.5M 행이있는 테이블에서 비교적 간단한 쿼리가 있습니다.

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)! 쿼리는 최대 절전 모드에서 생성되므로 변경하기가 상당히 어려우며 일부 기능을 사용할 수 없습니다 (예 : UNION사용할 수 없으므로 빠름).

질문

1. 두 번째 경우에 색인을 사용할 수없는 이유는 무엇입니까? 그들은 어떻게 사용될 수 있습니까?
2. 다른 방법으로 쿼리 성능을 향상시킬 수 있습니까?

추가 생각

SELECT를 수동으로 수행 한 다음 결과 목록을 쿼리에 넣어 첫 번째 경우를 사용할 수 있습니다. IN () 목록에 5000 개의 숫자가 있어도 두 번째 솔루션보다 4 배 빠릅니다. 그러나 그것은 잘못 된 것처럼 보입니다 (또한 100 배 빠를 수도 있습니다 :)). 쿼리 플래너가이 두 쿼리에 대해 완전히 다른 방법을 사용하는 이유를 완전히 이해할 수 없으므로이 문제에 대한 더 좋은 해결책을 찾고 싶습니다.

문제의 핵심은 여기서 명백해집니다.

게시 시퀀 스 스캔 (비용 = 0.01..349652.84 행 = 744661 너비 = 8) (실제 시간 = 2735.888..2841.393 행 = 1 루프 = 1)

Postgres 는 744661 개의 행을 반환하지만 실제로는 단일 행으로 판명됩니다. Postgres가 쿼리에서 무엇을 기대해야하는지 잘 모르면 더 잘 계획 할 수 없습니다. 실제 쿼리는 숨겨져 (SELECT 9762715)있어야하며 테이블 정의, 제한 조건, 카디널리티 및 데이터 분배도 알고 있어야합니다. 분명히, Postgres는 얼마나 적은 행이 반환 되는지 예측할 수 없습니다 . 이 내용에 따라 쿼리를 다시 작성하는 방법이있을 수 있다 .

하위 쿼리가 행을 초과하여 반환 할 수 없다는 것을 알고 있다면 다음 n을 사용하여 Postgres에 알릴 수 있습니다.

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

경우 n이 충분히 작은이며, 포스트 그레스 (비트 맵) 인덱스 스캔으로 전환됩니다. 그러나 간단한 경우에만 작동합니다. OR조건을 추가 할 때 작업이 중지됩니다 . 쿼리 플래너는 현재 그에 대처할 수 없습니다.

나는 거의 처음 IN (SELECT ...)부터 사용하지 않습니다 . 일반적으로 EXISTSsemi-join을 사용하여 동일한 방법을 구현하는 더 좋은 방법이 있습니다. 때로는 ( LEFT) JOIN( LATERAL) ...

확실한 해결책은을 사용하는 UNION것이지만, 당신은 그것을 배제했습니다. 실제 하위 쿼리 및 기타 관련 세부 정보를 모른 채 더 이상 말할 수 없습니다.

동료가 쿼리를 변경하여 간단한 다시 쓰기가 필요하고 수행해야 할 작업, 즉 한 단계에서 하위 선택을 수행 한 다음 결과에 대한 추가 작업을 수행 할 수있는 방법을 찾았습니다.

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

Explain 분석은 다음과 같습니다.

 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

이 방법으로 모든 하위 선택을 찾아 다시 쓰는 간단한 파서를 만들 수 있으며 기본 쿼리를 조작하기 위해 최대 절전 모드 후크에 추가 할 수 있습니다.

두 번째 질문에 대한 답변 : 예. 하위 쿼리에 ORDER BY를 추가하면 긍정적 인 영향을 미칩니다. 그러나 성능면에서 "EXISTS (하위 쿼리)"솔루션과 유사합니다. 하위 쿼리의 경우에도 두 행이 만들어 지므로 큰 차이가 있습니다.

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