"Also sprach Tom Lane:"
> > It may still be useful. The kernel won't necessarily send data as you
> > push it down to the network protocols and driver. The driver may decide
> > to wait for more data to accumulate,
>
> No, because we set TCP_NODELAY. Once we've flushed a message to the
That just means "disable Nagle", which is indeed more or less the
correct thing to do .. you don't want to sit around waiting for more
data when we're sure there will be none, as you say. Yet you also don't
want to send short data out prematurely, which disabling Nagle can
cause.
And disabling Nagle doesn't actually force data out immediately you want
it to be sent ... it just disables extra waits imposed by the Nagle
algorithm/protocol. It doesn't stop the driver from waiting around
because it feels taking the bus might be a bit premature right now,
for example.
> kernel, we don't want the kernel sitting on it --- any delay there adds
> directly to the elapsed query time. At least this is the case for the
> final response to a query. I'm not too clear on whether this means we
> need to be careful about intermediate message boundaries when there's a
> lot of data being sent.
It's unclear. But not my situation.
If I clear TCP_CORK all data is sent at that point. If I set TCP_CORK
data is held until I clear TCP_CORK, or 200ms have passed with no send.
Peter