Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: ptb(at)inv(dot)it(dot)uc3m(dot)es
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-28 21:08:14
Message-ID: 200705282108.l4SL8ED06035@momjian.us (view raw or flat)
Thread:
Lists: pgsql-performance
Please let us know if there is something we should change in the
PostgreSQL source code.

---------------------------------------------------------------------------

Peter T. Breuer wrote:
> "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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>                 http://www.postgresql.org/about/donate

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-performance by date

Next:From: Jim NasbyDate: 2007-05-29 00:48:00
Subject: Re: Feature suggestion : FAST CLUSTER
Previous:From: Simon RiggsDate: 2007-05-28 20:40:08
Subject: Re: PITR performance costs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group