Re: Change GUC hashtable to use simplehash?

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <gurjeet(at)singh(dot)im>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Change GUC hashtable to use simplehash?
Date: 2023-12-10 14:57:04
Message-ID: CANWCAZbajMKw=F=v91xY69HSm7CEw4z5CrFC2rZoYipD1EBR4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:

> On Sun, Dec 10, 2023 at 2:18 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >
> > On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > > > I tested using the new hash function APIs for my search path cache,
> > > > and
> > > > there's a significant speedup for cases not benefiting from
> > > > a86c61c9ee.
> > > > It's enough that we almost don't need a86c61c9ee. So a definite +1
> > > > to
> > > > the new APIs.
>
> Interesting, thanks for testing! SearchPathCache is a better starting
> point than dynahash for removing strlen calls anyway -- it's more
> localized, uses simplehash, and we can test it with at-hand tests.

Since I had to fix a misalignment in the original to keep ubsan from
crashing CI anyway (v8-0005), I thought I'd take the experiment with
search path cache and put the temporary validation of the hash
function output in there (v8-0004). I had to finagle a bit to get the
bytewise interface to give the same answer as the original, but that's
okay: The bytewise interface is intended for when we don't know the
length up front (and therefore the internal seed can't be tweaked with
the length), but it's nice to make sure nothing's broken.

There is also a chunkwise version for search path cache. That might be
a little faster. Perf testing can be done as is, because I put the
validation in assert builds only.

I've left out the GUC stuff for now, just want to get CI green again.

Attachment Content-Type Size
v8-0003-Add-bytewise-interface.patch text/x-patch 2.1 KB
v8-0002-Rewrite-fasthash-functions-using-a-homegrown-incr.patch text/x-patch 5.8 KB
v8-0004-Assert-that-the-fasthash-variants-give-or-can-giv.patch text/x-patch 4.4 KB
v8-0005-Fix-alignment-issue-in-the-original-fastash.patch text/x-patch 815 bytes
v8-0001-Vendor-fasthash.patch text/x-patch 3.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-12-10 23:07:59 Re: GUC names in messages
Previous Message Amit Kapila 2023-12-10 11:03:35 Re: Synchronizing slots from primary to standby