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 answer several times, and I think I understand now what you mean. You mean "it doesn't use index _7 because the status IN (0,1,2) isn't usable". I didn't think about that, but that's another good point. Instead, I meant: Why can't I just delete index _1, if anyway I have index _7 with the same field, just plus additional fields. I thought that would be redundant: Index _1 = mailbox_idnr Index _7 = mailbox_idnr,status,seen_flag So I would guess that Index _1 is redundant, and I can delete it because the planner will use _7 instead. After all, for searching any mailbox_idnr in that table (~234k entries) it doesn't really matter if you use index _1 or _7, the sort is the same (if you don't care about the other fields). 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
