From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Creager <Robert_Creager(at)LogicalChaos(dot)org> |
Cc: | PGPerformance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: This query is still running after 10 hours... |
Date: | 2004-09-28 15:04:23 |
Message-ID: | 14842.1096383863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Robert Creager <Robert_Creager(at)LogicalChaos(dot)org> writes:
> Normally, this query takes from 5 minutes to 2 hours to run. On this update, it's been running for more than 10 hours.
> ...
> -> Nested Loop (cost=250.69..129094.19 rows=77211 width=59)
> -> Hash Join (cost=250.69..307.34 rows=67 width=12)
> Hash Cond: ("outer".pair_id = "inner".pair_id)
> ...
It chose a nested loop here because it was only expecting 67 rows out of
the next-lower join, and so it thought it would only need 67 repetitions
of the index probe into obs_v_file_id_index. I'm suspicious that that
estimate was way low and so the nestloop is taking forever. You might
try "SET enable_nestloop = off" as a crude way of avoiding that trap.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-09-28 17:53:53 | Interest in perf testing? |
Previous Message | Gaetano Mendola | 2004-09-28 14:55:13 | Re: This query is still running after 10 hours... |