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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ptb(at)inv(dot)it(dot)uc3m(dot)es
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: general PG network slowness (possible cure) (repost)
Date: 2007-05-25 14:07:14
Message-ID: 8448.1180102034@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Peter T. Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)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

In response to

Browse pgsql-performance by date

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