| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()? |
| Date: | 2024-07-12 15:58:30 |
| Message-ID: | ZpFSpuCkAM5_urg8@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 12, 2024 at 12:01:11PM +0200, Antonin Houska wrote:
> Nathan Bossart <nathandbossart(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-07-12 16:08:24 | Re: Can't find bugs to work on |
| Previous Message | Tom Lane | 2024-07-12 15:44:25 | Re: Can't find bugs to work on |