From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | John Naylor <johncnaylorls(at)gmail(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-09 19:18:15 |
Message-ID: | b40292c99e623defe5eadedab1d438cf51a4107c.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
v1-0001-Use-new-hash-APIs-for-search-path-cache.patch | text/x-patch | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sutou Kouhei | 2023-12-09 20:44:07 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Peter Geoghegan | 2023-12-09 18:38:57 | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |