Re: A better way than tweaking NTUP_PER_BUCKET

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: A better way than tweaking NTUP_PER_BUCKET
Дата
Msg-id CA+U5nMJsGwNV+Z8FMAcfNLJ30Ya-yKzhzZrVdjN+bY81gMX6dQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A better way than tweaking NTUP_PER_BUCKET  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: A better way than tweaking NTUP_PER_BUCKET  (Jeremy Harris <jgh@wizmail.org>)
Re: A better way than tweaking NTUP_PER_BUCKET  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
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.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Failure while inserting parent tuple to B-tree is not fun