Re: Remove traces of long in dynahash.c

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove traces of long in dynahash.c
Date: 2025-08-22 05:09:51
Message-ID: aKf7nwGMztNf-NUI@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 21, 2025 at 12:53:09AM -0400, Tom Lane wrote:
> If you prefer to regard this as an independent issue, that's okay with
> me ... but it's touching most of the same lines of code, so it seems
> to me that it'd be about as easy to deal with both items at once.

I'd rather do that after a second look at the whole picture as this
led to an accumulation of bullet points. The long->int64 switch was
looking OK on its own and I have applied it.

Attached is the second piece of refactoring, where I have introduced a
couple more APIs in pg_bitutils.h (cross-checked the resulting
computations of the old and new routines with some quick hacks, in
case, and they matched):
pg_nextpower2_32_bound, replacing next_pow2_int
pg_nextpower2_64_bound, replacing next_pow2_int64
pg_ceil_log2_64_bound, replacing my_log2()
pg_ceil_log2_32_bound, not used, present for symmetry.

An extra thing is a suggested change for pg_nextpower2_32(), to use a
uint64 instead of a uint32 as argument, which is caused by
next_pow2_int64() and next_pow2_int(), that both used int64
previously.

There's likely some opinion differences according to one's taste;
that's my idea of the refactoring to remove the duplication.
--
Michael

Attachment Content-Type Size
0001-Clean-up-next-pow2-routines-of-dynahash.c-moving-to-.patch text/x-diff 11.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-08-22 05:23:22 Re: Remove unneeded cast in heap_xlog_lock.
Previous Message Amit Kapila 2025-08-22 04:08:25 Re: Logical Replication of sequences