Re: general PG network slowness (possible cure) (repost) - Mailing list pgsql-performance

From Tom Lane
Subject Re: general PG network slowness (possible cure) (repost)
Date
Msg-id 9508.1180106418@sss.pgh.pa.us
Whole thread Raw
In response to Re: general PG network slowness (possible cure) (repost)  ("Peter T. Breuer" <ptb@inv.it.uc3m.es>)
Responses Re: general PG network slowness (possible cure) (repost)
List pgsql-performance
"Peter T. Breuer" <ptb@inv.it.uc3m.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

pgsql-performance by date:

Previous
From: "Peter T. Breuer"
Date:
Subject: Re: general PG network slowness (possible cure) (repost)
Next
From: "Andreas Kostyrka"
Date:
Subject: Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13))