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 8448.1180102034@sss.pgh.pa.us
Whole thread Raw
In response to general PG network slowness (possible cure) (repost)  ("Peter T. Breuer" <ptb@inv.it.uc3m.es>)
List 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 by date:

Previous
From: Bastian Voigt
Date:
Subject: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))
Next
From: Richard Huxton
Date:
Subject: Re: general PG network slowness (possible cure) (repost)