Andres Freund <and...@anarazel.de> writes:
> On 2020-03-07 13:54:57 -0500, Tom Lane wrote:
>> This seems way overcomplicated compared to what I suggested (ie,
>> just let internal_putbytes bypass the buffer in cases where the
>> data would get flushed next time through its loop anyway).
> Well, we quite frequently send out multiple messages in a row, without a
> flush inbetween. It'd be nice if we could avoid both copying buffers for
> each message, as well as allocating a new stringinfo.
That gets you right into the situation where trouble adding more messages
could corrupt/destroy messages that were supposedly already sent (but in
reality aren't flushed to the client quite yet). I really think that
there is not enough win available here to justify introducing that kind
of fragility.
To be blunt, no actual evidence has been offered in this thread that
it's worth changing anything at all in this area. All of the bytes
in question eventually have to be delivered to the client, which is
going to involve two kernel-space/user-space copy steps along with
who-knows-what network transmission overhead. The idea that an
extra process-local memcpy or two is significant compared to that
seems like mostly wishful thinking to me.
regards, tom lane
