faifaiOn Sat, 7 Mar 2020 at 02:45, Andres Freund wrote:
>
> Hi,
>
> On March 5, 2020 1:23:21 PM PST, Aleksei Ivanov 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
Andres Freund 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
Hi,
On 2020-03-07 13:54:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > 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 =
Andres Freund writes:
> 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
> }
This
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
*>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
Hi,
On March 5, 2020 1:23:21 PM PST, Aleksei Ivanov 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
On Fri, 6 Mar 2020 at 07:27, Aleksei Ivanov wrote:
>
> > 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
*> 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
Aleksei Ivanov 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.
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?
Besides, if we already have a ready message packet to be sent why should we
wait?
Waiting for your reply,
Best regards!
On
Aleksei Ivanov writes:
> I am really curious what was the original intention of using the
> PqSendBuffer and is it possible to remove it now.
> Currently all messages are copied from StringInfo to this buffer and sent,
> which from my point of view is redundant operation.
That would mean doing
Dear community,
I am really curious what was the original intention of using the
PqSendBuffer and is it possible to remove it now.
Currently all messages are copied from StringInfo to this buffer and sent,
which from my point of view is redundant operation.
It is possible to directly send
13 matches
Mail list logo
