Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)
Date
Msg-id 20180707200158.wpqkd7rjr4jxq5g7@alap3.anarazel.de
Whole thread Raw
In response to Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)  (Andres Freund <andres@anarazel.de>)
Responses Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)  (Robert Haas <robertmhaas@gmail.com>)
Re: Faster str to int conversion (was Table with large number of intcolumns, very slow COPY FROM)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2017-12-08 13:44:37 -0800, Andres Freund wrote:
> On 2017-12-08 10:17:34 -0800, Andres Freund wrote:
> > the strtoll is libc functionality triggered by pg_atoi(), something I've
> > seen show up in numerous profiles. I think it's probably time to have
> > our own optimized version of it rather than relying on libcs.
> 
> Attached is a hand-rolled version. After quickly hacking up one from
> scratch, I noticed we already kind of have one for int64 (scanint8), so
> I changed the structure of this one to be relatively similar.
> 
> It's currently using the overflow logic from [1], but that's not
> fundamentally required, we could rely on fwrapv for this one too.
> 
> This one improves performance of the submitted workload from 1223.950ms
> to 1020.640ms (best of three). The profile's shape changes quite
> noticeably:

FWIW, here's a rebased version of this patch. Could probably be polished
further. One might argue that we should do a bit more wide ranging
changes, to convert scanint8 and pg_atoi to be also unified. But it
might also just be worthwhile to apply without those, given the
performance benefit.

Anybody have an opinion on that?

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: How can we submit code patches that implement our (pending)patents?
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().