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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: general PG network slowness (possible cure) (repost)
Дата
Msg-id 8448.1180102034@sss.pgh.pa.us
обсуждение исходный текст
Ответ на general PG network slowness (possible cure) (repost)  ("Peter T. Breuer" <ptb@inv.it.uc3m.es>)
Список pgsql-performance
"Peter T. Breuer" <ptb@inv.it.uc3m.es> writes:
> Soooo ... I took a look at my implementation of remote gdbm, and did
> a very little work to aggregate outgoing transmissions together into
> lumps.

We do that already --- for a simple query/response such as you are
describing, each query cycle will involve one physical client->server
message followed by one physical server->client message.  The only way
to aggregate more is for the application code to merge queries together.

Migrating a dbm-style application to a SQL database is often a real
pain, precisely because the application is designed to a mindset of
"fetch one record, manipulate it, update it", where "fetch" and "update"
are assumed to be too stupid to do any of the work for you.  The way
to get high performance with a SQL engine is to push as much of the work
as you can to the database side, and let the engine process multiple
records per query; and that can easily mean rewriting the app from the
ground up :-(

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Bastian Voigt
Дата:
Сообщение: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: general PG network slowness (possible cure) (repost)