Re: A better way than tweaking NTUP_PER_BUCKET

Поиск
Список
Период
Сортировка
От Jeremy Harris
Тема Re: A better way than tweaking NTUP_PER_BUCKET
Дата
Msg-id 52E78753.90103@wizmail.org
обсуждение исходный текст
Ответ на Re: A better way than tweaking NTUP_PER_BUCKET  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 27/01/14 18:00, Simon Riggs wrote:
> On 27 January 2014 17:44, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>> This topic is interesting - we found very bad performance with hashing large
>> tables with high work_mem. MergeJoin with quicksort was significantly
>> faster.
>
> I've seen this also.
>
>> I didn't deeper research - there is a possibility of virtualization
>> overhead.
>
> I took measurements and the effect was repeatable and happened for all
> sizes of work_mem, but nothing more to add.

FWIW my current list-based internal merge seems to perform worse at
larger work-mem, compared to quicksort.   I've been starting to wonder
if the rate of new ram-chip page opens is an issue (along with the
more-usually considered cache effects).  Any random-access workload
would be affected by this, if it really exists.
-- 
Cheers,   Jeremy




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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Infinite recursion in row-security based on updatable s.b. views
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: PoC: Partial sort