| 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: | Whole Thread | Raw Message | 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
| 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 |