Re: Speedup usages of pg_*toa() functions - Mailing list pgsql-hackers

From David Rowley
Subject Re: Speedup usages of pg_*toa() functions
Date
Msg-id CAApHDvoUjNo-xhOhrYQQYxykfu_aLswohfLsF15PzrCDKiDbxg@mail.gmail.com
Whole thread Raw
In response to Re: Speedup usages of pg_*toa() functions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On Tue, 9 Jun 2020 at 19:24, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>
> >>>>> "David" == David Rowley <dgrowleyml@gmail.com> writes:
>
>  David> As you can see, this squeezes about 5% extra out of a copy of a
>  David> 10 million row bigint table but costs us almost 3% on an
>  David> equivalent int table.
>
> And once again I have to issue the reminder: you can have gains or
> losses of several percent on microbenchmarks of this kind just by
> touching unrelated pieces of code that are never used in the test. In
> order to demonstrate a consistent difference, you have to do each set of
> tests multiple times, with random amounts of padding added to some
> unrelated part of the code.

Thanks for the reminder.

Instead of that, I tried with clang 10.0.0.  I was previously using gcc 9.3.

BIGINT test

Master: latency average = 1842.182 ms
Patched: latency average = 1715.418 ms

INT test

Master: latency average = 1650.583 ms
Patched: latency average = 1617.783 ms

There's nothing in the patch that makes the INT test faster, so I
guess that's noise.  The BIGINT test is about 7.3% faster in this
case.

David



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unify drop-by-OID functions
Next
From: Masahiko Sawada
Date:
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view