Re: Endless loop in ExecNestLoop
От | Tom Lane |
---|---|
Тема | Re: Endless loop in ExecNestLoop |
Дата | |
Msg-id | 8467.1138639377@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Endless loop in ExecNestLoop (Philipp Reisner <philipp.reisner@linbit.com>) |
Ответы |
Re: Endless loop in ExecNestLoop
Re: [Sd-log] Re: Endless loop in ExecNestLoop |
Список | pgsql-bugs |
Philipp Reisner <philipp.reisner@linbit.com> writes: > Version: 8.0.2 I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0. > Is this bug-report of any use so far ? Not a lot. You need to find out what the difference is between the cases where the query runs quickly and those where it doesn't. I'm betting that the planner is choosing a very bad plan in the slow cases, but there's not a lot of evidence here to show what or why. The explain analyze output shows two levels of hash join underneath four levels of nestloop join, whereas the stack trace looks like there are five levels of nestloop and only one hash. So this is some evidence that a different plan is being used in the slow cases. The stack trace doesn't provide nearly enough info about what that plan is, though. Do you have geqo_threshold set to less than its default value? Do you sometimes execute the query with different sets of parameters? Either of these might lead to changes of plan. regards, tom lane
В списке pgsql-bugs по дате отправления: