Re: Proposal: PqSendBuffer removal

Hi,

On March 5, 2020 1:23:21 PM PST, Aleksei Ivanov <iv.alekseii@gmail.com> wrote:
>Thank you for your reply!
>
>Yes, you are right there will be a separate call to send the data, but
>is
>copying data each time more costly operation than just one syscall?

Yes, it's very likely to be more expensive to execute a syscall in a lot of cases. They've gotten a lot more expensive
withall the security issues.  

>Besides, if we already have a ready message packet to be sent why
>should we
>wait?

In a lot of cases we'll send a number of small messages after each other. We don't want to send those out separately,
that'djust increase overhead. 


But in some paths/workloads the copy is quite noticable. I've mused before whether we could extend StringInfo to handle
caseslike this. E.g. by having StringInfo have two lengths. One that is the offset to the start of the allocated memory
(0for plain StringInfos), and one for the length of the string being built. 

Then we could get a StringInfo pointing directly to the current insertion point in the send buffer.  To support growing
it,enlargeStringInfo would first subtract the offset to the start of the allocation, and then reallocate that.  

I can imagine that bring useful in a number of places. And because there only would be additional overhead when
actuallygrowing the StringInfo, I don't think the cost would be measurable. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.