Re: bad estimation together with large work_mem generates terrible slow hash joins

Поиск
Список
Период
Сортировка
От 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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Aussie timezone database changes incoming
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Scaling shared buffer eviction