Re: Small optimization with expanding dynamic hash table - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: Small optimization with expanding dynamic hash table
Date
Msg-id CAH2L28sYmXEm7vHqkc0Sdf_P=pqyiPUSyrZHyqTTa8fby0Q8kA@mail.gmail.com
Whole thread Raw
List pgsql-hackers
Hi,
 
If I understand correctly, we only need to check the specific bit to determine whether a hash element needs relocation: 

diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c
index 1ad155d446e..32fbae71995 100644
--- a/src/backend/utils/hash/dynahash.c
+++ b/src/backend/utils/hash/dynahash.c
@@ -1626,7 +1626,7 @@ expand_table(HTAB *hashp)
                 currElement = nextElement)
        {
                nextElement = currElement->link;
-               if ((long) calc_bucket(hctl, currElement->hashvalue) == old_bucket)
+               if (!(currElement->hashvalue & (hctl->low_mask + 1)))
                {
                        *oldlink = currElement;
                        oldlink = &currElement->link;


Will this still work if new_bucket is not equal to hctl->low_mask + 1? 

The above situation seems possible because we increment new_bucket every time expand_table is called,
but we only update low_mask when new_bucket exceeds high_mask.  
 
This change has successfully passed the tests on Github CI. According to [1], the code has decent test coverage,
but I'm not certain if the specific case mentioned above is included in the tests.  

[1] LCOV - PostgreSQL 19devel - src/backend/utils/hash/dynahash.c

Thank you,
Rahila Syed

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: A recent message added to pg_upgade
Next
From: Konstantin Knizhnik
Date:
Subject: Logical replication prefetch