Re: Remove fls(), use pg_bitutils.h facilities instead?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: Remove fls(), use pg_bitutils.h facilities instead?
Date: 2022-07-20 05:44:35
Message-ID: CA+hUKGJ8YWFH7xmFwN+deGpcMBKAxXLjLUYisE6E_NwYtpq8VA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 20, 2022 at 5:26 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Wed, Jul 20, 2022 at 4:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I think we could probably just drop fls() entirely. It doesn't look
> > to me like any of the existing callers expect a zero argument, so they
> > could be converted to use pg_leftmost_one_pos32() pretty trivially.
> > I don't see that fls() is buying us anything that is worth requiring
> > readers to know yet another nonstandard function.
>
> That was not true for the case in contiguous_pages_to_segment_bin(),
> in dsa.c. If it's just one place like that (and, hrrm, curiously
> there is an open issue about binning quality on my to do list...),
> then perhaps we should just open code it there. The attached doesn't
> trigger the assertion that work != 0 in a simple make check.

That double eval macro wasn't nice. This time with a static inline function.

Attachment Content-Type Size
v3-0001-Remove-fls-function.patch text/x-patch 9.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2022-07-20 05:56:38 Re: Memory leak fix in psql
Previous Message Bharath Rupireddy 2022-07-20 05:34:58 Re: Expose last replayed timeline ID along with last replayed LSN