| 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: | Whole Thread | Raw Message | 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... |