To: ptb@inv.it.uc3m.es
cc: pgsql-performance@postgresql.org
Subject: Re: general PG network slowness (possible cure) (repost) 
In-reply-to: <200705250850.l4P8owm02940@inv.it.uc3m.es> 
References: <200705250850.l4P8owm02940@inv.it.uc3m.es>
Comments: In-reply-to "Peter T. Breuer" <ptb@inv.it.uc3m.es>
	message dated "Fri, 25 May 2007 10:50:58 +0200"
Date: Fri, 25 May 2007 10:07:14 -0400
Message-ID: <8448.1180102034@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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