Message-ID: <42AAC593.4050406@streppone.it>
Date: Sat, 11 Jun 2005 13:05:55 +0200
From: Cosimo Streppone <cosimo@streppone.it>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
MIME-Version: 1.0
To: Postgresql Performance list <pgsql-performance@postgresql.org>
Subject: Re: faster search
References: <20050610132812.R94573@vbp2.vbp2.com>
	<20050610201240.GA9822@gp.word-to-the-wise.com>
In-Reply-To: <20050610201240.GA9822@gp.word-to-the-wise.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steve Atkins wrote:

> On Fri, Jun 10, 2005 at 01:45:05PM -0400, Clark Slater wrote:
> 
>>Hi-
>>
>>Would someone please enlighten me as
>>to why I'm not seeing a faster execution
>>time on the simple scenario below?
> 
 > [...]
 >
> Create an index on (productlistid, typeid, partnumber) then
> 
>   select * from test where productlistid=3 and typeid=9
>    order by productlistid, typeid, partnumber LIMIT 15;
> 

Clark, try also adding (just for testing) partnumber to your
where clause, like this:

    select * from test where productlistid=3 and typeid=9
    and partnumber='foo' order by productlistid,
    typeid, partnumber;

and check output of explain analyze.

I had experiences of planner "bad" use of indexes when attribute
types were integer and cardinality was low (a single attribute
value, like "typeid=9" selects one or few rows).
However, this was on 7.1.3, and probably is not relevant to your case.

-- 
Cosimo