On Mittwoch 21 Januar 2009 Alvaro Herrera wrote:
> Seems like the problem is that it is not pushing the "status IN"
> condition as part of the index condition for some reason, and instead
> using it as a filter. Maybe something to do with the selectivity of
> that clause?
I was reading your answe
On Mittwoch 21 Januar 2009 Tom Lane wrote:
> No, AFAIR the planner will *always* include every possibly relevant
> condition for a given index. If the condition is useless or nearly
> so, that might prompt it to pick a different index instead, but not
> to omit the indexqual. I'm thinking it's no
Alvaro Herrera writes:
> Seems like the problem is that it is not pushing the "status IN"
> condition as part of the index condition for some reason, and instead
> using it as a filter. Maybe something to do with the selectivity of
> that clause?
No, AFAIR the planner will *always* include every
On Mittwoch 21 Januar 2009 Alvaro Herrera wrote:
> Seems like the problem is that it is not pushing the "status IN"
> condition as part of the index condition for some reason, and instead
> using it as a filter. Maybe something to do with the selectivity of
> that clause?
I was reading your answe
Michael Monnerie wrote:
> EXPLAIN ANALYZE SELECT 1 FROM dbmail_messages msg JOIN
> dbmail_physmessage pm ON ( pm.id = msg.physmessage_id ) WHERE
> message_idnr BETWEEN 3178782 AND 3616157 AND mailbox_idnr = 3236 AND
> status IN (0,1,2) ORDER BY message_idnr ASC;
[...]
> -> Bitmap H
http://www.postgresql.org/docs/8.3/interactive/using-explain.html
I tried reading that page, but it's still not clear to me, why the index
dbmail_messages_1 is better than dbmail_messages_7:
\d dbmail_messages
Tabelle »public.dbmail_messages«
Spalte |
