Re: bad estimation together with large work_mem generates terrible slow hash joins
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: bad estimation together with large work_mem generates terrible slow hash joins |
| Дата | |
| Msg-id | 15702.1410443999@sss.pgh.pa.us обсуждение |
| Ответ на | Re: bad estimation together with large work_mem generates terrible slow hash joins (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: bad estimation together with large work_mem generates
terrible slow hash joins
|
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> With the exception of ExecChooseHashTableSize() and a lot of stylistic
> issues along the lines of what I've already complained about, this
> patch seems pretty good to me. It does three things:
> ...
> (3) It allows the number of batches to increase on the fly while the
> hash join is in process. This case arises when we initially estimate
> that we only need a small hash table, and then it turns out that there
> are more tuples than we expect. Without this code, the hash table's
> load factor gets too high and things start to suck.
Pardon me for not having read the patch yet, but what part of (3)
wasn't there already?
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера