Hi,
On 2020-03-06 11:09:23 -0800, Aleksei Ivanov wrote:
> *>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.
Could you expand a bit on what you see as the problem? Because I'm not
following?
What does any of this have to do with realloc performance? I mean, the
buffer would just scale up once, so the cost of that would be very
quickly amortized?
What I'm thinking is that we'd have pg_beginmessage() (potentially a
different named version) initialize the relevant StringInfo basically as
(StringInfoData){
.data = PqSendPointer,
.len = 0,
.alloc_offset = PqSendBuffer - PqSendBuffer
}
and that pq_endmessage would then advance the equivalent (see below [1]) of
what today is PqSendPointer to be PqSendPointer += StringInfo->len;
That'd mean that we'd never need to copy data in/out the send buffer
anymore, because we'd directly construct the message in the send
buffer. Pretty much all important FE/BE communication goes through
pq_beginmessage[_reuse()].
We'd have to add some defenses against building multiple messages at the
same time. But neither do I think that is common, nor does it seem hard
to defend againt: A simple counter should do the trick?
Regards,
Andres
[1] Obviously the above sketch doesn't quite work that way. We can't
just have stringinfo reallocate the buffer. Feels quite solvable though.
