Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller
Date
Msg-id 20140610155842.GV2556@tamriel.snowman.net
Whole thread Raw
In response to Re: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Next
From: Robert Haas
Date:
Subject: Re: Proposing pg_hibernate