From: | Michael Monnerie <michael(dot)monnerie(at)is(dot)it-management(dot)at> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Question on Index usage |
Date: | 2009-01-21 14:58:57 |
Message-ID: | 200901211558.58053@zmi.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
From | Date | Subject | |
---|---|---|---|
Next Message | paulo matadr | 2009-01-21 15:02:06 | Res: [GENERAL] bytea size limit? |
Previous Message | Alvaro Herrera | 2009-01-21 14:28:29 | Re: Question on Index usage |