On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan <LCohan@web.com> wrote:
> Please see updated attachment that includes the tables involved in the si=
mple query below and all their indexes. We believe that the performance iss=
ue is due to the query not using any index but doing seq scans instead and =
this is very little related to the knowledge from the link you posted below=
. As you can see we picked a simple query with INNER JOIN between two index=
ed tables where postgres 8.3 and 9.0 decides to not use existing indexes fo=
r whatever reason.
Have you tried using enable_seqscan =3D off and looked at the explain outpu=
t then?
I think you'll find Postgres is choosing not to use the indexes
because they're just not helpful. If you disable seqscan it should use
the indexes but I expect it will be slower. The current plan is doing
a single pass through both tables using entirely sequential i/o.
That's about as fast as you could hope for it to be as your query does
require reading all the data.
--=20
greg