| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | ptb(at)inv(dot)it(dot)uc3m(dot)es |
| Cc: | "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 15:20:18 |
| Message-ID: | 9508.1180106418@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Peter T. Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es> writes:
> And definitely all those could be grouped if there are several to do.
Except that in the situation you're describing, there's only a hundred
or two bytes of response to each query, which means that only one send()
will occur anyway. (The flush call comes only when we are done
responding to the current client query.)
It's possible that for bulk data transmission situations we could
optimize things a bit better --- in particular I've wondered whether we
can reliably find out the MTU of the connection and use that as the
output buffer size, instead of trusting the kernel to choose the best
message boundaries --- but for the situation you're worried about
there will be only one send.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Kostyrka | 2007-05-25 15:20:23 | Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13)) |
| Previous Message | Peter T. Breuer | 2007-05-25 15:06:10 | Re: general PG network slowness (possible cure) (repost) |