Date: Fri, 12 Jul 2024 10:58:30 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Antonin Houska <ah@cybertec.at>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Missed opportunity for bsearch() in
 TransactionIdIsCurrentTransactionId()?
Message-ID: <ZpFSpuCkAM5_urg8@nathan>
References: <36977.1720623613@antos>
 <Zo7aA2m35vGR56MN@nathan>
 <47366.1720778471@antos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47366.1720778471@antos>
Archived-At: <https://www.postgresql.org/message-id/ZpFSpuCkAM5_urg8%40nathan>
Precedence: bulk

On Fri, Jul 12, 2024 at 12:01:11PM +0200, Antonin Houska wrote:
> Nathan Bossart <nathandbossart@gmail.com> wrote:
>> My concern with switching them to bsearch() would be the performance impact
>> of using a function pointer for the comparisons.  Perhaps we could add a
>> couple of inlined binary search implementations for common types to replace
>> many of the open-coded ones.
> 
> bsearch() appears to be used widely, but o.k., I don't insist on using it to
> replace the existing open-coded searches.

Sorry, I didn't mean to say that I was totally against switching to
bsearch(), but I do think we need to understand whether there is any
performance impact before doing so, especially in hot paths.  It would be
nice if we could reduce the number of open-coded binary searches in some
fashion, and if we can maintain or improve performance by creating a
handful of static inline functions, that would be even better.  If there's
no apparent performance difference, bsearch() is probably fine.

-- 
nathan