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 по дате отправления: