>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 thought about it yesterday and one issue with this approach is how would you known the length of the packet to be sent. As we can’t returned back in PqSendBuffer. Also realloc is quite expensive operation.
Previously I suggested to include offset into stringinfo and if it is large enough we will have an opportunity to send it directly and it will not required a lot of changes.
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 with all 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'd just increase overhead.
But in some paths/workloads the copy is quite noticable. I've mused before whether we could extend StringInfo to handle cases like this. E.g. by having StringInfo have two lengths. One that is the offset to the start of the allocated memory (0 for 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 actually growing 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.
