Re: Division in dynahash.c due to HASH_FFACTOR - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Division in dynahash.c due to HASH_FFACTOR
Date
Msg-id CA+hUKGKHm8Ejh26W8AUhNvfh3sH9mZ5yuV9Eg15b4HtX6fcrgg@mail.gmail.com
Whole thread Raw
In response to Re: Division in dynahash.c due to HASH_FFACTOR  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Responses Re: Division in dynahash.c due to HASH_FFACTOR  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Tue, Sep 8, 2020 at 11:17 PM Jakub Wartak <Jakub.Wartak@tomtom.com> wrote:
> I agree with both, I just thought it might be interesting finding as this idiv might be (?) present in other common
pathslike ReadBuffer*() / PinBuffer() (some recent discussions, maybe on NUMA boxes), not just WAL recovery as it seems
relativelyeasy to improve. 

I wrote a draft commit message for Jakub's proposed change (attached),
and did a little bit of testing, but I haven't seen a case where it
wins yet; I need to work on something else now but thought I'd share
this much anyway.  One observation is that the rule in init_htab had
better agree with the expansion rule in hash_search_with_hash_value,
otherwise you can size your hash table perfectly for n elements and
then it still has to expand when you insert the nth element, which is
why I changed >= to >.  Does this make sense?  Oh man, I don't like
the mash-up of int, long, uint32, Size dynahash uses in various places
and that are brought into relief by that comparison...

Attachment

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: extension patch of CREATE OR REPLACE TRIGGER
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: SIGQUIT handling, redux