Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E67C1632564 for ; Wed, 21 Jan 2009 11:32:53 -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 99513-01-4 for ; Wed, 21 Jan 2009 11:32:46 -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 55E02632530 for ; Wed, 21 Jan 2009 11:32:45 -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 8DC1E42D for ; Wed, 21 Jan 2009 16:32:41 +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 95582400155 for ; Wed, 21 Jan 2009 16:32:41 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: pgsql-admin@postgresql.org Subject: Re: Question on Index usage Date: Wed, 21 Jan 2009 16:32:41 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.10-ZMI; KDE/4.1.3; x86_64; ; ) References: <200901210854.28091@zmi.at> <20090121142829.GE4038@alvh.no-ip.org> <2116.1232551538@sss.pgh.pa.us> In-Reply-To: <2116.1232551538@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901211632.41348@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/92 X-Sequence-Number: 31139 On Mittwoch 21 Januar 2009 Tom Lane wrote: > No, AFAIR the planner will *always* include every possibly relevant > condition for a given index. =A0If the condition is useless or nearly > so, that might prompt it to pick a different index instead, but not > to omit the indexqual. =A0I'm thinking it's not believing it can use > the status condition with that index, perhaps for datatype reasons. > =A0What is status declared as, exactly? OK, now I'm sure you're speaking in a direction I didn't mean ;-) But still, it could use the index _7 for the status field, as that's=20 sorted and 0,1,2 would be all together. status | smallint | not null default (0)::smallint Maybe it doesn't do because it could well be 0,1,3 also, and it's not=20 checking if all the values in the IN() statement appear in a row? > Also, what PG version is this? 8.3 on openSUSE 11.1: select version(); PostgreSQL 8.3.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (SUSE=20 Linux) 4.3.2 [gcc-4_3-branch revision 141291] 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