| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | fburgess(at)radiantblue(dot)com |
| Cc: | Jaime Casanova <jaime(at)2ndquadrant(dot)com>, psql performance list <pgsql-performance(at)postgresql(dot)org>, Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Very slow inner join query Unacceptable latency. |
| Date: | 2013-05-23 00:17:26 |
| Message-ID: | CAMkU=1xYWuQ0pAB0NhdZ=Jf5tGms1_q93ZkRA8AKBeKRNR=MJQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
On Wed, May 22, 2013 at 7:41 AM, <fburgess(at)radiantblue(dot)com> wrote:
> PostgreSQL 9.1.6 on linux
>
From the numbers in your attached plan, it seems like it should be doing a
nested loop from the 580 rows (it thinks) that match in SARS_ACTS_RUN
against the index on sars_run_id to pull out the 3297 rows (again, it
think, though it is way of there). I can't see why it would not do that.
There were some planner issues in the early 9.2 releases that caused very
large indexes to be punished, but I don't think those were in 9.1
Could you "set enable_hashjoin to off" and post the "explain analyze" that
that gives?
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Onorato | 2013-05-23 00:27:10 | Re: Table Partitioning |
| Previous Message | Neeraj Rai | 2013-05-22 23:55:03 | Re: - pgaql long value corrupted using htons |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2013-05-23 01:01:56 | Re: Reliability with RAID 10 SSD and Streaming Replication |
| Previous Message | Merlin Moncure | 2013-05-22 23:37:39 | Re: Reliability with RAID 10 SSD and Streaming Replication |