Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller
Дата
Msg-id 20140610155842.GV2556@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
> If we could allow NTUP_PER_BUCKET to drop when the hashtable is
> expected to fit in memory either way, perhaps with some safety margin
> (e.g. we expect to use less than 75% of work_mem), I bet that would
> make the people who have been complaining about this issue happy.  And
> probably a few people who haven't been complaining, too: I don't
> recall the precise performance numbers that were posted before, but
> ISTR the difference between 10 and 1 was pretty dramatic.

This is more-or-less what I had been hoping to find time to do.  As Tom
points out, more testing is needed, and there's still the trade-off
between "fits-in-L2" and "doesn't" which can make a pretty big
difference while building the hash table.  Of course, once it's built,
it's faster to use it when it's larger as there are fewer collisions.

I do plan to come back to this and will hopefully find time over the
next few months.
Thanks,
    Stephen

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

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Proposing pg_hibernate