Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g7SmX-0002Um-Ha for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Oct 2018 22:04:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g7SmV-0005ad-Kr for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Oct 2018 22:04:39 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g7SmV-0005a6-Ad for pgsql-hackers@lists.postgresql.org; Tue, 02 Oct 2018 22:04:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g7SmS-0006vb-So for pgsql-hackers@lists.postgresql.org; Tue, 02 Oct 2018 22:04:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w92M4X4h030899; Tue, 2 Oct 2018 18:04:34 -0400 From: Tom Lane To: Andres Freund cc: Alexander Kuzmenkov , pgsql-hackers@lists.postgresql.org Subject: Re: Performance improvements for src/port/snprintf.c In-reply-to: <20181002201328.kauaofescppm54gq@alap3.anarazel.de> References: <15785.1536776055@sss.pgh.pa.us> <20180926220419.lorxpb564gakdjkz@alap3.anarazel.de> <20180926221814.el5nwmkez6zfmzbz@alap3.anarazel.de> <14302.1538005507@sss.pgh.pa.us> <20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de> <15882.1538007944@sss.pgh.pa.us> <20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de> <20180927005705.shbl3n5hq3t65n2j@alap3.anarazel.de> <20180927011814.kpncoksuqq3gy44s@alap3.anarazel.de> <15652.1538011825@sss.pgh.pa.us> <20181002201328.kauaofescppm54gq@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 02 Oct 2018 13:13:28 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30897.1538517873.1@sss.pgh.pa.us> Date: Tue, 02 Oct 2018 18:04:33 -0400 Message-ID: <30898.1538517873@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund 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