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

From: "Peter T(dot) Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Peter T(dot) Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es>, "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 15:06:10
Message-ID: 200705251506.l4PF6AW08031@inv.it.uc3m.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Also sprach Alvaro Herrera:"
> > I really think it would be worthwhile getting some developer to tell me
> > where the network send is done in PG.
>
> See src/backend/libpq/pqcomm.c (particularly internal_flush()).

Yes. Thanks. That looks like it. It calls secure_write continually
until the buffer is empty.

Secure_write is located ibe-secure.c, but I'm not using ssl, so the
call reduces to just

n = send(port->sock, ptr, len, 0);

And definitely all those could be grouped if there are several to do.
But under normal circumstances the send will be pushing against a
lttle resistance (the copy to the driver/protocol stack buffer is faster
than the physical network send, by a ratio of GB/s to MB/s, or 1000 to
1), and thus all these sends will probably complete as a single unit
once they have been started.

It's worth a try. I thought first this may be too low level, but it
looks as though internal_flush is only triggered when some other buffer
is full, or deliberately, so it may be useful to block until it fires.

I'll try it.

Peter

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-05-25 15:20:18 Re: general PG network slowness (possible cure) (repost)
Previous Message Tom Lane 2007-05-25 14:28:38 Re: Big problem with sql update operation