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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
