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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: general PG network slowness (possible cure) (repost)
Дата
Msg-id 9508.1180106418@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: general PG network slowness (possible cure) (repost)  ("Peter T. Breuer" <ptb@inv.it.uc3m.es>)
Ответы Re: general PG network slowness (possible cure) (repost)
Список 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 по дате отправления:

Предыдущее
От: "Peter T. Breuer"
Дата:
Сообщение: Re: general PG network slowness (possible cure) (repost)
Следующее
От: "Andreas Kostyrka"
Дата:
Сообщение: Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13))