Re: This query is still running after 10 hours...
| От | Tom Lane |
|---|---|
| Тема | Re: This query is still running after 10 hours... |
| Дата | |
| Msg-id | 14842.1096383863@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | This query is still running after 10 hours... (Robert Creager <Robert_Creager@LogicalChaos.org>) |
| Ответы |
Re: This query is still running after 10 hours...
|
| Список | pgsql-performance |
Robert Creager <Robert_Creager@LogicalChaos.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
В списке pgsql-performance по дате отправления: