Re: general PG network slowness (possible cure) (repost)

From: "Peter T(dot) Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: ptb(at)inv(dot)it(dot)uc3m(dot)es, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: general PG network slowness (possible cure) (repost)
Date: 2007-05-25 16:34:36
Message-ID: 200705251634.l4PGYak16803@inv.it.uc3m.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message PFC 2007-05-25 16:51:04 Re: LIKE search and performance
Previous Message Tom Lane 2007-05-25 16:16:21 Re: general PG network slowness (possible cure) (repost)