Re: refactoring - share str2*int64 functions

Hi,

On 2019-07-18 09:28:28 +0900, Michael Paquier wrote:
> 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.

A static inline would be fine, depending on how you do that. I'm not
quite sure what you mean with "inner wrapper" - isn't a wrapper normally
outside?

I'd probably do something like

static inline int64
strtoint64(const char *str)
{
int64 res;

e = strtoint64_e(str, &res);
if (likely(e == STRTOINT_OK))
return res;
else
{
report_strtoint_error(str, e, "int64");
return 0; /* pacify compiler */
}
}

and then have one non-inline report_strtoint_error() shared across the
various functions. Even leaving code-duplication aside, not having the
elog call itself in the inline function is nice, as that's quite a few
instructions.

Greetings,

Andres Freund