無限制查詢的運行速度快於限制查詢的速度

-1

具有限制100的相同查詢的運行速度慢於沒有限制100的類似查詢的速度慢的原因是什麼？兩個查詢針對同一個數據庫運行，結果集小於100無限制查詢的運行速度快於限制查詢的速度

最初的查詢是由hibernate生成的，並有一些額外的連接。基於我得到的反饋，我讓查詢變得更簡單並且運行

VACUUM FULL ANALYZE events 
VACUUM FULL ANALYZE resources

但是問題依然存在。

謝謝！

explain ANALYZE 
SELECT e.id 
FROM events e, 
    resources r 
WHERE e.resource_id = r.id 
    AND (resource_type_id = '19872817' OR resource_type_id = '282') 
ORDER BY occurrence_date DESC LIMIT 100

輸出...

"Limit (cost=0.98..86362.46 rows=100 width=12) (actual time=61958.090..185854.425 rows=22 loops=1)" 
" -> Nested Loop (cost=0.98..16791263.94 rows=19443 width=12) (actual time=61958.087..185854.392 rows=22 loops=1)" 
"  -> Index Scan using eventoccurrencedateindex on events e (cost=0.56..2295556.29 rows=31819630 width=16) (actual time=0.028..31770.948 rows=31819491 loops=1)" 
"  -> Index Scan using resources_pkey on resources r (cost=0.42..0.45 rows=1 width=4) (actual time=0.004..0.004 rows=0 loops=31819491)" 
"    Index Cond: (id = e.resource_id)" 
"    Filter: ((resource_type_id = 19872817) OR (resource_type_id = 282))" 
"    Rows Removed by Filter: 1" 
"Total runtime: 185854.569 ms"

和

explain ANALYZE 
SELECT e.id 
FROM events e, 
    resources r 
WHERE e.resource_id = r.id 
    AND (resource_type_id = '19872817' OR resource_type_id = '282') 
ORDER BY occurrence_date DESC

輸出...

"Sort (cost=455353.69..455402.30 rows=19443 width=12) (actual time=1.942..1.947 rows=22 loops=1)" 
" Sort Key: e.occurrence_date" 
" Sort Method: quicksort Memory: 26kB" 
" -> Nested Loop (cost=42.30..453968.67 rows=19443 width=12) (actual time=0.720..1.900 rows=22 loops=1)" 
"  -> Bitmap Heap Scan on resources r (cost=9.53..309.53 rows=86 width=4) (actual time=0.120..0.306 rows=34 loops=1)" 
"    Recheck Cond: ((resource_type_id = 19872817) OR (resource_type_id = 282))" 
"    -> BitmapOr (cost=9.53..9.53 rows=86 width=0) (actual time=0.109..0.109 rows=0 loops=1)" 
"     -> Bitmap Index Scan on resources_type_fk_index (cost=0.00..4.74 rows=43 width=0) (actual time=0.016..0.016 rows=0 loops=1)" 
"       Index Cond: (resource_type_id = 19872817)" 
"     -> Bitmap Index Scan on resources_type_fk_index (cost=0.00..4.74 rows=43 width=0) (actual time=0.092..0.092 rows=34 loops=1)" 
"       Index Cond: (resource_type_id = 282)" 
"  -> Bitmap Heap Scan on events e (cost=32.78..5259.29 rows=1582 width=16) (actual time=0.041..0.043 rows=1 loops=34)" 
"    Recheck Cond: (resource_id = r.id)" 
"    -> Bitmap Index Scan on events_resource_fk_index (cost=0.00..32.38 rows=1582 width=0) (actual time=0.037..0.037 rows=1 loops=34)" 
"     Index Cond: (resource_id = r.id)" 
"Total runtime: 2.054 ms"

來源

2014-12-29 user1409708

如果觀察到的行數與預期的不同 - >>您的統計數據不存在或不存在。 – joop

爲什麼在您需要INNER JOIN時左連接？以及爲什麼使用兩個沒有在任何地方使用的表？是的，LIMIT有一些問題，但在你的情況下，你應該先修復你的查詢。 –

你運行的是哪個版本的PostgreSQL？它看起來像這個錯誤報告：http://www.postgresql.org/message-id/[email protected] –

增加極限尺寸爲1000的Postgres造成使用不同的計劃工作速度更快。

來源

2015-01-05 15:01:04 user1409708

無限制查詢的運行速度快於限制查詢的速度

回答

相關問題