Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()?
От | Nathan Bossart |
---|---|
Тема | Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()? |
Дата | |
Msg-id | ZpFSpuCkAM5_urg8@nathan обсуждение исходный текст |
Ответ на | Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()? (Antonin Houska <ah@cybertec.at>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: