Re: general PG network slowness (possible cure) (repost)
От | Peter T. Breuer |
---|---|
Тема | Re: general PG network slowness (possible cure) (repost) |
Дата | |
Msg-id | 200705251634.l4PGYak16803@inv.it.uc3m.es обсуждение исходный текст |
Ответ на | Re: general PG network slowness (possible cure) (repost) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: general PG network slowness (possible cure)
(repost)
|
Список | pgsql-performance |
"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
В списке pgsql-performance по дате отправления: