From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Fetter <david@fetter.org>
cc: Jeff Janes <jeff.janes@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Why is pq_begintypsend so slow?
In-reply-to: <5450.1578797036@sss.pgh.pa.us>
References: 
 <CAMkU=1whbRDUwa4eayD9+59K-coxO9senDkPRbTn3cg0pUz4AQ@mail.gmail.com>
 <31795.1578773977@sss.pgh.pa.us> <20200112014107.GC32763@fetter.org>
 <5450.1578797036@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 11 Jan 2020 21:43:56 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28763.1578799965.1@sss.pgh.pa.us>
Date: Sat, 11 Jan 2020 22:32:45 -0500
Message-ID: <28764.1578799965@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I saw at this point that the remaining top spots were
> enlargeStringInfo and appendBinaryStringInfo, so I experimented
> with inlining them (again, see patch below).  That *did* move
> the needle: down to 72691 ms, or 20% better than HEAD.

Oh ... marking the test in the inline part of enlargeStringInfo()
as unlikely() helps quite a bit more: 66100 ms, a further 9% gain.
Might be over-optimizing for this particular case, perhaps, but
I think that's a reasonable marking given that we overallocate
the stringinfo buffer for most uses.

(But ... I'm not finding these numbers to be super reproducible
across different ASLR layouts.  So take it with a grain of salt.)

			regards, tom lane