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

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: bad estimation together with large work_mem generates terrible slow hash joins
Дата
Msg-id 5410BE22.1060907@fuzzy.cz
обсуждение исходный текст
Ответ на 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
On 10.9.2014 21:34, Robert Haas wrote:
> On Wed, Sep 10, 2014 at 3:12 PM, Tomas Vondra <tv@fuzzy.cz> wrote:
>> On 10.9.2014 20:25, Heikki Linnakangas wrote:
>>> On 09/10/2014 01:49 AM, Tomas Vondra wrote:
>>>> I also did a few 'minor' changes to the dense allocation patch, most
>>>> notably:
>>>>
>>>> * renamed HashChunk/HashChunkData to MemoryChunk/MemoryChunkData
>>>>    The original naming seemed a bit awkward.
>>>
>>> That's too easy to confuse with regular MemoryContext and AllocChunk
>>> stuff. I renamed it to HashMemoryChunk.
>>
>> BTW this breaks the second patch, which is allocating new chunks when
>> resizing the hash table. Should I rebase the patch, or can the commiter
>> do s/MemoryChunk/HashMemoryChunk/ ?
>>
>> Assuming there are no more fixes needed, of course.
>
> Rebasing it will save the committer time, which will increase the
> chances that one will look at your patch.  So it's highly recommended.

OK. So here's v13 of the patch, reflecting this change.

regards
Tomas

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Memory Alignment in Postgres
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Need Multixact Freezing Docs