Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id 20190718002828.GA1416@paquier.xyz
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Andres Freund <andres@anarazel.de>)
Responses Re: refactoring - share str2*int64 functions  (Andres Freund <andres@anarazel.de>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Custom table AMs need to include heapam.h because of BulkInsertState
Next
From: Michael Paquier
Date:
Subject: Re: Add parallelism and glibc dependent only options to reindexdb