Re: refactoring - share str2*int64 functions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: refactoring - share str2*int64 functions
Дата
Msg-id 20190718002828.GA1416@paquier.xyz
обсуждение исходный текст
Ответ на Re: refactoring - share str2*int64 functions  (Andres Freund <andres@anarazel.de>)
Ответы Re: refactoring - share str2*int64 functions  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Wed, Jul 17, 2019 at 11:14:28AM -0700, Andres Freund wrote:
> That'd be considerably slower, so I'm *strongly* against that. These
> conversion routines are *really* hot in a number of workloads,
> e.g. bulk-loading with COPY.  Check e.g.
> https://www.postgresql.org/message-id/20171208214437.qgn6zdltyq5hmjpk%40alap3.anarazel.de

Thanks for the link.  That makes sense!  So stacking more function
calls could also be an issue.  Even if using static inline for the
inner wrapper?  That may sound like a stupid question but you have
likely more experience than me regarding that with profiling.

> I doubt it - it's not of that long-standing vintage (23a27b039d9,
> 2016-03-12), and if so they are very likely to use base 10. We shouldn't
> keep some barely tested function around, just for the hypothetical
> scenario that some extension uses it. Especially if that function is
> considerably slower than the potential replacement.

Okay, I won't fight hard on that either.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Custom table AMs need to include heapam.h because of BulkInsertState
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add parallelism and glibc dependent only options to reindexdb