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 10:54:45
Message-ID: CAApHDvp0diOMoHp1DRP-kfOZ5wkBr=ZkZAEwdk0rbr8U+mA0EQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 9 Jun 2020 at 22:08, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>
> >>>>> "David" == David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>
> David> This allows us to speed up a few cases. int2vectorout() should
> David> be faster and int8out() becomes a bit faster if we get rid of
> David> the strdup() call and replace it with a palloc()/memcpy() call.
>
> What about removing the memcpy entirely? I don't think we save anything
> much useful here by pallocing the exact length, rather than doing what
> int4out does and palloc a fixed size and convert the int directly into
> it.

On looking back through git blame, it seems int2out and int4out have
been that way since at least 1996, before int8.c existed. int8out has
been doing it since fa838876e9f -- Include 8-byte integer type. dated
1998. Quite likely the larger than required palloc size back then was
more of a concern. So perhaps you're right about just doing it that
way instead. With that and the ints I tested with, the int8
performance should be about aligned to int4 performance.

> For pg_ltoa, etc., I don't like adding the extra call to pg_ultoa_n - at
> least on my clang, that results in two copies of pg_ultoa_n inlined.
> How about doing it like,
>
> int
> pg_lltoa(int64 value, char *a)
> {
> int len = 0;
> uint64 uvalue = value;
>
> if (value < 0)
> {
> uvalue = (uint64) 0 - uvalue;
> a[len++] = '-';
> }
> len += pg_ulltoa_n(uvalue, a + len);
> a[len] = '\0';
> return len;
> }

Agreed, that seems better.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-06-09 11:20:29 Re: Bump default wal_level to logical
Previous Message Georgios 2020-06-09 10:29:44 Include access method in listTables output