From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Lawrence Cohan <LCohan(at)web(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Postgres not using indexes |
Date: | 2011-03-31 17:28:50 |
Message-ID: | AANLkTikniFOL=SN1-xdWSJ+TrOmiN4xGxPqZSXd3yyVP@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan <LCohan(at)web(dot)com> wrote:
> Please see updated attachment that includes the tables involved in the simple query below and all their indexes. We believe that the performance issue 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 indexed tables where postgres 8.3 and 9.0 decides to not use existing indexes for whatever reason.
Have you tried using enable_seqscan = off and looked at the explain output 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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2011-03-31 19:45:43 | Re: BUG #5961: JDBC Driver acceptURL does not check 'jdbc:postgresql:' |
Previous Message | Robert Haas | 2011-03-31 15:11:49 | Re: BUG #5856: pg_attribute.attinhcount is not correct. |