| От | Craig Ringer |
|---|---|
| Тема | Re: BUG #4945: Parallel update(s) gone wild |
| Дата | |
| Msg-id | 1248761635.10632.248.camel@wallace.localnet обсуждение исходный текст |
| Ответ на | BUG #4945: Parallel update(s) gone wild ("dan boeriu" <dan.boeriu@roost.com>) |
| Список | pgsql-bugs |
Please reply to the list, not directly to me. > I don't think is that simple. The VERY SAME statement runs twice - one > finishes in about 20 secs the other doesn't finish in 24 hours. Yep, OK, so it's not just a planning or scaling issue. Have you checked pg_locks ? SELECT * FROM pg_locks; What does pg_stat_activity indicate about the query? SELECT * FROM pg_stat_activity; > The plan might change from one execution to the other - is there a way > to get the executed plan at runtime? I think there is in 8.4, but I haven't moved up to it and tested yet. Not in previous versions. -- Craig Ringer
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера