From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksei Ivanov <iv(dot)alekseii(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Proposal: PqSendBuffer removal |
Date: | 2020-03-05 23:04:41 |
Message-ID: | 14283.1583449481@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-05 23:08:27 | Re: Allowing ALTER TYPE to change storage strategy |
Previous Message | Fabien COELHO | 2020-03-05 22:55:04 | Re: pgbench: option delaying queries till connections establishment? |