Re: Improve performance of pg_strtointNN functions - Mailing list pgsql-hackers

From David Rowley
Subject Re: Improve performance of pg_strtointNN functions
Date
Msg-id CAApHDvpiAUuY_da-i0HoiVO7CcH=SWJ4MXm76rQsZc1rRvQHig@mail.gmail.com
Whole thread Raw
In response to Re: Improve performance of pg_strtointNN functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Improve performance of pg_strtointNN functions  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Fri, 2 Dec 2022 at 20:35, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> If we are happy with this patch, then it's okay with me if you push this
> first.  I'll probably need to do another pass over my patch anyway, so a
> bit more work isn't a problem.

Thanks. I'll start looking at the patch again now. If I don't find any
problems then I'll push it.

I just did some performance tests by COPYing in 40 million INTs
ranging from -/+ 20 million.

create table ab(a int, b int);
insert into ab select x,x from generate_series(-20000000,20000000)x;
copy ab to '/tmp/ab.csv';

-- master
truncate ab; copy ab from '/tmp/ab.csv';
Time: 10219.386 ms (00:10.219)
Time: 10252.572 ms (00:10.253)
Time: 10202.940 ms (00:10.203)

-- patched
truncate ab; copy ab from '/tmp/ab.csv';
Time: 9522.020 ms (00:09.522)
Time: 9441.294 ms (00:09.441)
Time: 9432.834 ms (00:09.433)

About ~8% faster

David



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Next
From: David Rowley
Date:
Subject: Re: Improve performance of pg_strtointNN functions