Date: Fri, 10 Apr 2026 13:07:35 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: CharSyam <charsyam@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Use cached hash to skip unnecessary key comparisons in
 dshash
Message-ID: <adk8Z0HGDaXSRIgF@nathan>
References: 
 <CAMrLSE4JrhPB2XYMOMzbPSsgE+6kmDaKHKiF34NWdnbQts=Cpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAMrLSE4JrhPB2XYMOMzbPSsgE+6kmDaKHKiF34NWdnbQts=Cpw@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/adk8Z0HGDaXSRIgF%40nathan>
Precedence: bulk

On Sat, Apr 11, 2026 at 01:09:33AM +0900, CharSyam wrote:
> This patch adds a hash pre-check (item->hash == hash) before calling
> equal_keys() in both find_in_bucket() and delete_key_from_bucket().
> Items with non-matching hash values are skipped with a single integer
> comparison, avoiding the expensive key comparison entirely.

This relies on the fact that matching keys will have matching hashes, but
matching hashes does not necessarily imply matching keys.  IIUC this is a
safe assumption, although a short comment to this effect might be a nice
addition.

>   Test                     | Before    | After     | Improvement
>   -------------------------+-----------+-----------+------------
>   INSERT 10000 entries     | 14.99 ms  |  9.46 ms  | ~37%
>   LOOKUP 10000 hits        | 10.40 ms  |  5.52 ms  | ~47%
>   LOOKUP 10000 misses      |  8.41 ms  |  4.95 ms  | ~41%
>   LOOKUP 50000 hits (x5)   | 33.48 ms  | 26.44 ms  | ~21%
> 
> The improvement is most significant when bucket chains are longer and key
> comparison is expensive (e.g., string keys).

Nice results.  Are there any regressions when the bucket chains are short
or when key comparisons are inexpensive?

> I believe this patch is ready for review.  I look forward to any feedback
> and am happy to make revisions.

We are in feature-freeze for PostgreSQL v19 now, so this will unfortunately
need to wait until July when v20 development begins.  Please add an entry
to the commitfest site to ensure this doesn't get lost:

	https://commitfest.postgresql.org/

-- 
nathan