Re: A better way than tweaking NTUP_PER_BUCKET

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: A better way than tweaking NTUP_PER_BUCKET
Дата
Msg-id 20140125220221.GR31026@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: A better way than tweaking NTUP_PER_BUCKET  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: A better way than tweaking NTUP_PER_BUCKET  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Bruce Momjian (bruce@momjian.us) wrote:
> Uh, were are we on this?  Is it a TODO?

I've been strongly considering my previous patch which tweaked
NTUP_PER_BUCKET to '1' (instead of the default '10') when there's
sufficient work_mem for it.  There was recently another complaint on IRC
about our tendency to hash the larger partition rather than the smaller
one which I believe would be resolved by doing so.

The main thing holding me back has been concern that there may be cases
which perform worse with the change, either because hashing the larger
partition actually ended up being faster or due to the increase in
memory usage.

In the end, I believe we absolutely should do something about this.
Hashing a 64M-row table (requiring upwards of 8G) instead of hashing
a 2M-row table is really bad of us.

Thoughts?
Thanks,
    Stephen

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A minor correction in comment in heaptuple.c
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)