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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

  From Date Subject
Next Message PFC 2008-04-09 18:41:29 Re: EXPLAIN detail
Previous Message Luigi N. Puleio 2008-04-09 14:44:23 Re: EXPLAIN detail