Re: Performance improvements for src/port/snprintf.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Performance improvements for src/port/snprintf.c
Date: 2018-10-02 22:04:33
Message-ID: 30898.1538517873@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> I've looked through the patch. Looks good to me. Some minor notes:

[ didn't see this till after sending my previous ]

> - How about adding our own strchrnul for the case where we don't
> HAVE_STRCHRNUL? It's possible that other platforms have something
> similar, and the code wouldlook more readable that way.

Sure, we could just make a "static inline strchrnul()" for use when
!HAVE_STRCHRNUL. No objection.

> - I know it's not new, but is it actually correct to use va_arg(args, int64)
> for ATYPE_LONGLONG?

Well, the problem with just doing s/int64/long long/g is that the
code would then fail on compilers without a "long long" type.
We could ifdef our way around that, but I don't think the code would
end up prettier.

Given that we only ever use "ll" modifiers via INT64_FORMAT, and that
that'll only be set to "ll" if int64 is indeed "long long", those code
paths should be dead code in any situation where the type pun is wrong.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2018-10-02 22:24:00 Re: Obtaining a more consistent view definition when a UNION subquery contains undecorated constants
Previous Message Tom Lane 2018-10-02 21:54:31 Re: Performance improvements for src/port/snprintf.c