Postgres使用較慢的索引與小限制

我有幾個不同的查詢，在某些情況下顯着減慢。

這一個是快：

SELECT 
    "posts".* 
FROM "posts" 
WHERE "posts"."source_id" IN (29949, 29952, 29950, 33642, 33626, 33627, 33625) 
AND "posts"."deleted_at" IS NULL 
AND "posts"."rejected_at" IS NULL 
ORDER BY POSITION ASC, external_created_at DESC; 
LIMIT 100 
OFFSET 0

這一個是慢：

SELECT 
    "posts".* 
FROM "posts" 
WHERE "posts"."source_id" IN (29949, 29952, 29950, 33642, 33626, 33627, 33625) 
AND "posts"."deleted_at" IS NULL 
AND "posts"."rejected_at" IS NULL 
ORDER BY POSITION ASC, external_created_at DESC; 
LIMIT 5 
OFFSET 0

這裏唯一的不同是極限。

最奇怪的是，一個非常類似的查詢＃2快：

SELECT 
    "posts".* 
FROM "posts" 
WHERE "posts"."source_id" IN (5868, 5867) 
AND "posts"."deleted_at" IS NULL 
AND "posts"."rejected_at" IS NULL 
ORDER BY POSITION ASC, external_created_at DESC; 
LIMIT 100 
OFFSET 0

這僅僅是通過較小範圍的source_ids

這裏尋找是所有三個查詢計劃：

EXPLAIN ANALYZE SELECT "posts".* FROM "posts" WHERE "posts"."source_id" IN (29949, 29952, 29950, 33642, 33626, 33627, 33625) AND "posts"."deleted_at" IS NULL AND "posts"."rejected_at" IS NULL ORDER BY POSITION ASC, external_created_at DESC LIMIT 100 OFFSET 0; 
---------------------------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=36900.88..36901.13 rows=100 width=1051) (actual time=104.564..104.570 rows=28 loops=1) 
    -> Sort (cost=36900.88..36926.01 rows=10052 width=1051) (actual time=104.559..104.563 rows=28 loops=1) 
     Sort Key: "position", external_created_at 
     Sort Method: quicksort Memory: 53kB 
     -> Index Scan using index_posts_on_source_id on posts (cost=0.44..36516.70 rows=10052 width=1051) (actual time=9.724..102.885 rows=28 loops=1) 
       Index Cond: (source_id = ANY ('{29949,29952,29950,33642,33626,33627,33625}'::integer[])) 
       Filter: ((deleted_at IS NULL) AND (rejected_at IS NULL)) 
       Rows Removed by Filter: 1737 
Total runtime: 105.774 ms 


EXPLAIN ANALYZE SELECT "posts".* FROM "posts" WHERE "posts"."source_id" IN (29949, 29952, 29950, 33642, 33626, 33627, 33625) AND "posts"."deleted_at" IS NULL AND "posts"."rejected_at" IS NULL ORDER BY POSITION ASC, external_created_at DESC LIMIT 5 OFFSET 0; 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Limit (cost=0.56..18788.72 rows=5 width=1051) (actual time=79611.044..314266.666 rows=5 loops=1) 
    -> Index Scan using index_posts_on_position_and_external_created_at on posts (cost=0.56..37771717.36 rows=10052 width=1051) (actual time=79610.677..314266.292 rows=5 loops=1) 
     Filter: ((deleted_at IS NULL) AND (rejected_at IS NULL) AND (source_id = ANY ('{29949,29952,29950,33642,33626,33627,33625}'::integer[]))) 
     Rows Removed by Filter: 3665332 
Total runtime: 314269.266 ms 


EXPLAIN ANALYZE SELECT "posts".* FROM "posts" WHERE "posts"."source_id" IN (5868, 5867) AND "posts"."deleted_at" IS NULL AND "posts"."rejected_at" IS NULL ORDER BY POSITION ASC, external_created_at DESC LIMIT 100 OFFSET 0; 
----------------------------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=10587.37..10587.62 rows=100 width=1051) (actual time=1017.476..1017.498 rows=100 loops=1) 
    -> Sort (cost=10587.37..10594.55 rows=2872 width=1051) (actual time=1017.474..1017.483 rows=100 loops=1) 
     Sort Key: "position", external_created_at 
     Sort Method: top-N heapsort Memory: 112kB 
     -> Index Scan using index_posts_on_source_id on posts (cost=0.44..10477.60 rows=2872 width=1051) (actual time=2.823..999.417 rows=4334 loops=1) 
       Index Cond: (source_id = ANY ('{5868,5867}'::integer[])) 
       Filter: ((deleted_at IS NULL) AND (rejected_at IS NULL)) 
       Rows Removed by Filter: 39 
Total runtime: 1017.669 ms

這裏是我的索引定義：

"posts_pkey" PRIMARY KEY, btree (id) 
"index_posts_on_deleted_at" btree (deleted_at) 
"index_posts_on_external_created_at" btree (external_created_at) 
"index_posts_on_external_id" btree (external_id) 
"index_posts_on_position" btree ("position") 
"index_posts_on_position_and_external_created_at" btree ("position", external_created_at DESC) 
"index_posts_on_rejected_at" btree (rejected_at) 
"index_posts_on_source_id" btree (source_id)

9.3.4

爲什麼使用Index Scan using index_posts_on_position_and_external_created_at on posts緩慢的一個時，另外兩個正在使用Index Scan using index_posts_on_source_id on posts：

我運行Postgres的版本？我該如何解決它？

來源

2015-12-15 goddamnyouryan

應該很明顯地包括表和索引定義以及Postgres版本。請[在這裏考慮指令]（http://stackoverflow.com/tags/postgresql-performance/info）並添加必要的信息。對於初學者來說，統計數據和/或成本估算可能會失敗。考慮：http://stackoverflow.com/a/8229000/939860 –

一個遲到的答案，萬一你仍然有這個問題，爲什麼不簡單地下降index_posts_on_position_and_external_created_at？正如你所說的，當查詢規劃器使用這個特定的索引時會出現問題。

你已經擁有這兩個指標：

"index_posts_on_external_created_at" btree (external_created_at) 
"index_posts_on_position" btree ("position")

這兩使index_posts_on_position_and_external_created_at非常多餘的，因爲PostgreSQL對一個給定的查詢中使用多個索引。如果您關心排序性能，您可以添加訂購到index_posts_on_external_created_at

來源

2016-04-17 13:00:05 e4c5

Postgres使用較慢的索引與小限制

回答

相關問題