Re: Speedup usages of pg_*toa() functions

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Speedup usages of pg_*toa() functions
Date: 2020-06-09 08:07:23
Message-ID: CAApHDvoUjNo-xhOhrYQQYxykfu_aLswohfLsF15PzrCDKiDbxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 9 Jun 2020 at 19:24, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>
> >>>>> "David" == David Rowley <dgrowleyml(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-06-09 08:07:39 Re: Read access for pg_monitor to pg_replication_origin_status view
Previous Message Peter Eisentraut 2020-06-09 07:55:27 Re: Unify drop-by-OID functions