Re: refactoring - share str2*int64 functions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: refactoring - share str2*int64 functions
Date: 2019-07-18 01:16:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.
> >
> 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

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;
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


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-07-18 01:20:18 Re: Custom table AMs need to include heapam.h because of BulkInsertState
Previous Message Andres Freund 2019-07-18 01:09:11 partition routing layering in nodeModifyTable.c