Re: Proposal: PqSendBuffer removal

*> What do you mean "just one syscall"? The entire point here is that
it'd take more syscalls to send the same amount of data.*

I mean that it messages are large enough more than 2K we will need 4
syscalls without copy it to the internal buffer, but currently we will copy
8K of messages and send it using 1 call. I think that under some threshold
of packet length it is redundant to copy it to internal buffer and the data
can be sent directly.

*> It does strike me that with the v3 protocol, we do sometimes have
caseswhere internal_putbytes is reached with a fairly large "len". If
we'veflushed out what's in PqSendBuffer to start with, and there's more
thana bufferload remaining in the source data, we could send the sourcedata
directly to output without copying it to the buffer first.That could
actually result in *fewer* kernel calls not more, if "len"is large enough.
But I strongly doubt that a code path that netsout to more kernel calls
will win.*

Yes, internal_putbytes can be updated to send data directly if the length
is more than internal buffer size.

On Thu, Mar 5, 2020 at 15:04 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Aleksei Ivanov <iv(dot)alekseii(at)gmail(dot)com> writes:
> > 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?
>
> What do you mean "just one syscall"? The entire point here is that it'd
> take more syscalls to send the same amount of data.
>
> It does strike me that with the v3 protocol, we do sometimes have cases
> where internal_putbytes is reached with a fairly large "len". If we've
> flushed out what's in PqSendBuffer to start with, and there's more than
> a bufferload remaining in the source data, we could send the source
> data directly to output without copying it to the buffer first.
> That could actually result in *fewer* kernel calls not more, if "len"
> is large enough. But I strongly doubt that a code path that nets
> out to more kernel calls will win.
>
> regards, tom lane
>