Re: bad estimation together with large work_mem generates terrible slow hash joins
В списке pgsql-hackers по дате отправления:
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: bad estimation together with large work_mem generates terrible slow hash joins |
| Дата | |
| Msg-id | 542CFA99.9070003@vmware.com обсуждение исходный текст |
| Ответ на | Re: bad estimation together with large work_mem generates terrible slow hash joins (Kevin Grittner <kgrittn@ymail.com>) |
| Ответы |
Re: bad estimation together with large work_mem generates terrible slow hash joins
|
| Список | pgsql-hackers |
On 10/02/2014 03:20 AM, Kevin Grittner wrote: > My only concern from the benchmarks is that it seemed like there > was a statistically significant increase in planning time: > > unpatched plan time average: 0.450 ms > patched plan time average: 0.536 ms > > That *might* just be noise, but it seems likely to be real. For > the improvement in run time, I'd put up with an extra 86us in > planning time per hash join; but if there's any way to shave some > of that off, all the better. The patch doesn't modify the planner at all, so it would be rather surprising if it increased planning time. I'm willing to just write that off as noise. - Heikki
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера