Message-ID: <47FCE0B3.3040307@postnewspapers.com.au>
Date: Wed, 09 Apr 2008 23:28:51 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "Luigi N. Puleio" <npuleio@rocketmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: EXPLAIN detail
References: <981759.47577.qm@web33504.mail.mud.yahoo.com>
In-Reply-To: <981759.47577.qm@web33504.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Luigi N. Puleio wrote:
>> If for some reason you cannot do that, please at least include the data
>> type of the primary key and all fields involved in the query, as well as
>> a list of all the indexes on both tables.
If you won't show people on the list your table definitions, or at least 
the information shown above, then it's less likely that anybody can help 
you or will spend the time trying to help you.

Personally I think you may need some functional/cast, and possibly 
composite, indexes to avoid the looping sequential scan as I said 
before. However, that's guesswork without some more information as 
repeatedly stated and requested. I'm not going to bother replying to any 
further mail just to say so again.


Try reading the documentation chapter about indexes:

http://www.postgresql.org/docs/current/static/indexes.html

and about query optimisation:

http://www.postgresql.org/docs/current/static/performance-tips.html

then experiment with various indexes to see what works best. Think about 
the data types. Remember that you can build an index on a cast of a 
field, on multiple fields, on function calls, or basically any other 
simple expression or expressions, but that complex indexes will cost 
more to build and maintain and might be bigger (and thus slower to search).


Anyway, I'm done.

--
Craig Ringer