Re: Performance improvements for src/port/snprintf.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance improvements for src/port/snprintf.c
Date
Msg-id 6094.1538591814@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance improvements for src/port/snprintf.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
>> Hm. I guess that'd be a bit better, but I'm not sure it's worth it. How
>> about we simply add a static assert that long long isn't bigger than
>> int64?

> WFM, I'll make it happen.

Actually, while writing a comment to go with that assertion, I decided
this was dumb.  If we're expecting the compiler to have "long long",
and if we're convinced that no platforms define "long long" as wider
than 64 bits, we may as well go with the s/int64/long long/g solution.
That should result in no code change on any platform today.  And it
will still work correctly, if maybe a bit inefficiently, on some
hypothetical future platform where long long is wider.  We (or our
successors) can worry about optimizing that when the time comes.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance improvements for src/port/snprintf.c
Next
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c