Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E4B16632564 for ; Wed, 21 Jan 2009 21:24:16 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 47800-05 for ; Wed, 21 Jan 2009 21:24:13 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by mail.postgresql.org (Postfix) with ESMTP id 07E8863251F for ; Wed, 21 Jan 2009 21:24:10 -0400 (AST) Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id ABDB3220B for ; Thu, 22 Jan 2009 02:24:07 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id F0FE9400155 for ; Thu, 22 Jan 2009 02:24:06 +0100 (CET) To: pgsql-admin@postgresql.org Subject: Re: Question on Index usage Content-Disposition: inline From: Michael Monnerie Organization: it-management http://it-management.at Date: Thu, 22 Jan 2009 02:24:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200901220224.05787@zmi.at> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/111 X-Sequence-Number: 31158 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. =A0Maybe something to do with the selectivity of > that clause? I was reading your answer several times, and I think I understand now=20 what you mean. You mean "it doesn't use index _7 because the status IN=20 (0,1,2) isn't usable". I didn't think about that, but that's another=20 good point. Instead, I meant: Why can't I just delete index _1, if anyway I have=20 index _7 with the same field, just plus additional fields. I thought=20 that would be redundant: Index _1 =3D mailbox_idnr Index _7 =3D mailbox_idnr,status,seen_flag So I would guess that Index _1 is redundant, and I can delete it because=20 the planner will use _7 instead. After all, for searching any=20 mailbox_idnr in that table (~234k entries) it doesn't really matter if=20 you use index _1 or _7, the sort is the same (if you don't care about=20 the other fields). mfg zmi =2D-=20 // 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