From: Antonin Houska <ah@cybertec.at>
cc: Thomas Munro <thomas.munro@enterprisedb.com>,
    Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Comment fix and question about dshash.c
In-reply-to: <15639.1540639321@localhost>
References: <8726.1540553521@localhost>
 <CAEepm=0RMoHPRovc5ugcPmKmaNRFUeZ+3bCf8uXbJ6Fx-1jCuQ@mail.gmail.com>
 <15639.1540639321@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Sat, 27 Oct 2018 13:22:01 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Sat, 27 Oct 2018 13:51:03 +0200
Message-ID: <16250.1540641063@localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

> Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>=20
> > On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska <ah@cybertec.at> wrote:
> >=20
> > 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 at a couple of general purpose hash
> > tables and saw that some used 0.75 and some used 1.0, as a wasted
> > 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.
>=20
> I don't know how exactly you apply the [1] formula (what is "n" and what =
is
> "N" in your case?), but my consideration was much simpler: For example, if
> BUCKETS_PER_PARTITION returns 8 (power of 2 is expected here and also more
> convenient), then MAX_COUNT_PER_PARTITION returns 8 / 2 + 8 / 4 =3D 6. Th=
us the
> hashtable gets resized if we're going to add the 7th entry to the partiti=
on,
> i.e. we the number of entries in the partition is lower than the number of
> buckets. Is that o.k.?

Well, it may be o.k. I've just checked what the fill factor means in hash
index and it's also the number of entries divided by the number of buckets.

--=20
Antonin Houska
Cybertec Sch=C3=B6nig & Sch=C3=B6nig GmbH
Gr=C3=B6hrm=C3=BChlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com