我有以下查詢:上Postgres SQL查詢忽略索引?
SELECT a.id, a.col2, b.id, b.col2, c.id, c.col2
FROM a
JOIN b on b.fk_a_id = a.id
JOIN c on c.fk_a_id = a.id
INNER JOIN d on d.fk_c_id = c.id
WHERE a.owner_id NOT IN (1, 3, 100, 41)
GROUP BY a.id, b.id, c.id
ORDER BY a.created_date desc
LIMIT __ OFFSET __
指標: a.id,a.owner_id,b.id,c.id
然而,沒有我的指標正在此查詢使用。我有另一個類似的查詢,其中有一個額外的表連接,正如我所期望的那樣使用索引關於爲什麼這個查詢沒有使用索引的任何想法?
編輯包括解釋:
"Limit (cost=7.88..7.89 rows=4 width=243) (actual time=175.824..175.825 rows=10 loops=1)"
" -> Sort (cost=7.88..7.89 rows=4 width=243) (actual time=175.822..175.822 rows=10 loops=1)"
" Sort Key: a.created_date DESC"
" Sort Method: quicksort Memory: 27kB"
" -> HashAggregate (cost=7.78..7.84 rows=4 width=243) (actual time=175.771..175.778 rows=10 loops=1)"
" Group Key: a.id, b.id, c.id"
" -> Hash Join (cost=5.12..7.75 rows=4 width=243) (actual time=0.072..0.099 rows=20 loops=1)"
" Hash Cond: (a.id = b.fk_a_id)"
" -> Hash Join (cost=2.85..5.43 rows=4 width=163) (actual time=0.041..0.063 rows=20 loops=1)"
" Hash Cond: (a.id = d.fk_a_id)"
" -> Seq Scan on table a (cost=0.00..2.44 rows=27 width=126) (actual time=0.008..0.025 rows=28 loops=1)"
" Filter: (owner_id <> ALL ('{1,3,100,41}'::bigint[]))"
" Rows Removed by Filter: 1"
" -> Hash (cost=2.76..2.76 rows=7 width=53) (actual time=0.027..0.027 rows=3 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 9kB"
" -> Hash Join (cost=1.16..2.76 rows=7 width=53) (actual time=0.019..0.023 rows=3 loops=1)"
" Hash Cond: (c.id = d.fk_c_id)"
" -> Seq Scan on table c (cost=0.00..1.39 rows=39 width=45) (actual time=0.002..0.004 rows=39 loops=1)"
" -> Hash (cost=1.07..1.07 rows=7 width=8) (actual time=0.007..0.007 rows=3 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 9kB"
" -> Seq Scan on table d (cost=0.00..1.07 rows=7 width=8) (actual time=0.003..0.004 rows=3 loops=1)"
" -> Hash (cost=2.12..2.12 rows=12 width=88) (actual time=0.022..0.022 rows=12 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 9kB"
" -> Seq Scan on table b (cost=0.00..2.12 rows=12 width=88) (actual time=0.005..0.013 rows=12 loops=1)"
"Planning time: 210.946 ms"
"Execution time: 175.987 ms"
'EXPLAIN'查詢併發布結果。 – Stavr00
哦,我知道爲什麼! Postgres優化器認爲全表掃描是執行查詢的最高性能方式。爲什麼它認爲,我不知道。優化器可以訪問大量我沒有的信息。 。 。表格大小,估計分佈,涉及的確切數據類型等等。 –
我剛剛編輯,包括EXPLAIN – Dayna