Why is that index not used? - Mailing list pgsql-admin
From | Michael Monnerie |
---|---|
Subject | Why is that index not used? |
Date | |
Msg-id | 200901211634.42228@zmi.at Whole thread Raw |
Responses |
Re: Why is that index not used?
Re: Why is that index not used? |
List | pgsql-admin |
I know I'm pedantic today but I have logs enabled to see every query done, and those who are called often should be as quick as possible, where they aren't - and I want to understand why... Can somebody explain me why on the last line, "dbmail_physmessage", there is a seq. scan going on and no index used? The query says "where pm.id = msg.physmessage_id", and there's an index on physmessage_id, so what's the problem? This takes 700 of the 900ms of the query, as there are 230k entries in physmessage. I see that that query is parallel to the index scan, but that's not a good choice I think. Wouldn't it be better to wait for the results of the "Filter message_idnr AND status" and then search only the fitting physmessage_id's? EXPLAIN ANALYZE SELECT seen_flag, answered_flag, deleted_flag, flagged_flag, draft_flag, recent_flag, TO_CHAR(internal_date, 'YYYY-MM- DD HH24:MI:SS' ), rfcsize, message_idnr FROM dbmail_messages msg, dbmail_physmessage pm WHERE pm.id = msg.physmessage_id AND message_idnr BETWEEN 3196318 AND 3619184 AND mailbox_idnr = 3241 AND status IN (0,1,2) ORDER BY message_idnr ASC; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Sort (cost=10466.09..10494.28 rows=11279 width=36) (actual time=856.412..872.783 rows=13258 loops=1) Sort Key: msg.message_idnr Sort Method: quicksort Memory: 1420kB -> Hash Join (cost=6880.89..9706.93 rows=11279 width=36) (actual time=702.001..822.022 rows=13258 loops=1) Hash Cond: (msg.physmessage_id = pm.id) -> Index Scan using dbmail_messages_1 on dbmail_messages msg (cost=0.00..2550.96 rows=11920 width=28) (actual time=0.123..30.881 rows=13258 loops=1) Index Cond: (mailbox_idnr = 3241) Filter: ((message_idnr >= 3196318) AND (message_idnr <= 3619184) AND (status = ANY ('{0,1,2}'::integer[]))) -> Hash (cost=4004.84..4004.84 rows=230084 width=24) (actual time=701.458..701.458 rows=229876 loops=1) -> Seq Scan on dbmail_physmessage pm (cost=0.00..4004.84 rows=230084 width=24) (actual time=0.015..319.395 rows=229876 loops=1) Total runtime: 897.722 ms \d dbmail_physmessage; id | bigint | not null default nextval('dbmail_physmessage_id_seq'::regclass) messagesize | bigint | not null default (0)::bigint rfcsize | bigint | not null default (0)::bigint internal_date | timestamp without time zone | Indexe: »dbmail_physmessage_pkey« PRIMARY KEY, btree (id) CLUSTER mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
pgsql-admin by date: