Speedup usages of pg_*toa() functions

Hi,

pg_itoa, pg_ltoa and pg_lltoa all have access to the length of the
string that is produced in the function by way of the "len" variable.
These functions don't have a great deal of use in core, but it seems
that most callers do require the len but end up getting it via
strlen(). It seems we could optimise this a little if we just had the
functions return the length instead of making callers do the work
themselves.

This allows us to speed up a few cases. int2vectorout() should be
faster and int8out() becomes a bit faster if we get rid of the
strdup() call and replace it with a palloc()/memcpy() call.

The slight drawback that I can see from this is that on testing
int4out() it gets slightly slower, which I assume is because I'm now
returning the length, but there's no use for it in that function.

create table bi (a bigint);
insert into bi select generate_Series(1,10000000);
vacuum freeze analyze bi;

bench.sql = copy bi to '/dev/null';

BIGINT test

drowley(at)amd3990x:~$ pgbench -n -f bench.sql -T 120 postgres

Master: latency average = 1791.597 ms
Patched: latency average = 1705.322 ms (95.184%)

INT test

create table i (a int);
insert into i select generate_Series(1,10000000);
vacuum freeze analyze i;

bench.sql = copy i to '/dev/null';

drowley(at)amd3990x:~$ pgbench -n -f bench.sql -T 120 postgres

Master: latency average = 1631.956 ms
Patched: latency average = 1678.626 ms (102.859%)

As you can see, this squeezes about 5% extra out of a copy of a 10
million row bigint table but costs us almost 3% on an equivalent int
table. A likely workaround for that is moving the functions into the
header file and making them static inline. It would be nice not to
have to do that though.

These tests were done on modern AMD hardware. I've not tested yet on
anything intel based.

I've copied in Andrew as I know he only recently rewrote these
functions and Andres since he did mention this in [1].

I'm interested to know if that int4out regression exists on other hardware.

David

[1] https://www.postgresql.org/message-id/20190920051857.2fhnvhvx4qdddviz@alap3.anarazel.de