แบบสอบถาม 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 จากนั้นใส่รายการผลลัพธ์ลงในคิวรี แม้จะมีหมายเลข 5000 ในรายการ IN () มันเร็วกว่าโซลูชันที่สองถึงสี่เท่า อย่างไรก็ตามดูเหมือนว่าผิด (เช่นอาจเร็วขึ้น 100 เท่า :)) มันไม่สามารถเข้าใจได้อย่างสมบูรณ์ว่าเหตุใดตัววางแผนคิวรีจึงใช้วิธีการที่แตกต่างไปจากเดิมอย่างสิ้นเชิงสำหรับเคียวรีสองรายการนี้ดังนั้นฉันจึงต้องการหาวิธีแก้ปัญหาที่ดีกว่าสำหรับปัญหานี้

แก่นของปัญหาชัดเจนที่นี่:

Seq สแกนบนสิ่งพิมพ์ (ราคา = 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มีขนาดเล็กเพียงพอ 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

ดูเหมือนว่าเราสามารถสร้าง parser ง่าย ๆ ที่ค้นหาและเขียนการเลือกย่อยทั้งหมดด้วยวิธีนี้และเพิ่มลงใน hook hibernate เพื่อจัดการเคียวรีเนทีฟ

ตอบคำถามที่สอง: ใช่คุณสามารถเพิ่ม ORDER BY ในแบบสอบถามย่อยของคุณซึ่งจะมีผลกระทบเชิงบวก แต่มันก็เป็นสิ่งสำคัญในการแก้ปัญหา "EXISTS (แบบสอบถามย่อย)" มีความแตกต่างอย่างมีนัยสำคัญแม้ว่าแบบสอบถามย่อยจะส่งผลให้มีสองแถว

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