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 по дате отправления: