From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: type cache cleanup improvements |
Date: | 2024-03-14 07:42:10 |
Message-ID: | ZfKqUpGb0XnWDen_@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 13, 2024 at 04:40:38PM +0300, Teodor Sigaev wrote:
> Done, all patches should be applied consequentially.
One thing that first pops out to me is that we can do the refactor of
hash_initial_lookup() as an independent piece, without the extra paths
introduced. But rather than returning the bucket hash and have the
bucket number as an in/out argument of hash_initial_lookup(), there is
an argument for reversing them: hash_search_with_hash_value() does not
care about the bucket number.
> 02-hash_seq_init_with_hash_value.v5.patch - introduces a
> hash_seq_init_with_hash_value() method. hash_initial_lookup() is marked as
> inline, but I suppose, modern compilers are smart enough to inline it
> automatically.
Likely so, though that does not hurt to show the intention to the
reader.
So I would like to suggest the attached patch for this first piece.
What do you think?
It may also be an idea to use `git format-patch` when generating a
series of patches. That makes for easier reviews.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
0001-Refactor-initial-hash-lookup-in-dynahash.c.patch | text/x-diff | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-03-14 08:06:31 | Re: Support json_errdetail in FRONTEND builds |
Previous Message | Bharath Rupireddy | 2024-03-14 07:38:23 | Re: LogwrtResult contended spinlock |