Skip site navigation (1) Skip section navigation (2)

Re: EXPLAIN detail

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: "Luigi N(dot) Puleio" <npuleio(at)rocketmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: EXPLAIN detail
Date: 2008-04-09 15:28:51
Message-ID: 47FCE0B3.3040307@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

pgsql-performance by date

Next:From: PFCDate: 2008-04-09 18:41:29
Subject: Re: EXPLAIN detail
Previous:From: Luigi N. PuleioDate: 2008-04-09 14:44:23
Subject: Re: EXPLAIN detail

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group