Re: Change GUC hashtable to use simplehash? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Change GUC hashtable to use simplehash?
Date
Msg-id b40292c99e623defe5eadedab1d438cf51a4107c.camel@j-davis.com
Whole thread Raw
In response to Re: Change GUC hashtable to use simplehash?  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: Change GUC hashtable to use simplehash?
Re: Change GUC hashtable to use simplehash?
List pgsql-hackers
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.
>
> Do you have a new test?

Still using the same basic test here:

https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com

What I did is:

   a. add your v5 patches
   b. disable optimization in a86c61c9ee
   c. add attached patch to use new hash APIs

I got a slowdown between (a) and (b), and then (c) closed the gap about
halfway. It started to get close to test noise at that point -- I could
get some better numbers out of it if it's helpful.

Also, what I'm doing in the attached path is using part of the key as
the seed. Is that a good idea or should the seed be zero or come from
somewhere else?

Regards,
    Jeff Davis



Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
Next
From: Sutou Kouhei
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations