On Sun, Oct 28, 2018 at 1:22 AM Tomas Vondra
wrote:
> On 10/27/2018 01:51 PM, Antonin Houska wrote:
> > Antonin Houska wrote:
> >> Thomas Munro wrote:
> >>> On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
> >>> Are you saying there is a bug in this logic (which is nbuckets * 0.75
> >>> e
On 10/27/2018 01:51 PM, Antonin Houska wrote:
Antonin Houska wrote:
Thomas Munro wrote:
On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
Are you saying there is a bug in this logic (which is nbuckets * 0.75
expressed as integer maths), or saying that 0.75 is not a good maximum
load
Antonin Houska wrote:
> Thomas Munro wrote:
>
> > On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
> >
> > Are you saying there is a bug in this logic (which is nbuckets * 0.75
> > expressed as integer maths), or saying that 0.75 is not a good maximum
> > load factor? I looked around a
Thomas Munro wrote:
> On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
>
> Thanks, will fix.
>
> > 2. Can anyone please explain this macro?
> >
> > /* Max entries before we need to grow. Half + quarter = 75% load factor. */
> > #define MAX_COUNT_PER_PARTITION(hash_table)
On Sat, Oct 27, 2018 at 10:03 AM Thomas Munro
wrote:
> space-vs-collision trade-off. If I have my maths right[1], with 0.75
> you expect to have 75 entries in ~53 buckets, but with 1.0 you expect
> to have 100 entries in ~64 buckets. It'd be a fair criticism that
Forgot to add: assuming 100 buc
On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
> 1. The return type of resize() function is void, so I propose part of the
> header comment to be removed:
>
> diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
> index b46f7c4cfd..b2b8fe60e1 100644
> --- a/src/backend/lib/dsha
