Message-ID: <4656EA22.4020801@archonet.com>
Date: Fri, 25 May 2007 14:52:34 +0100
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: ptb@inv.it.uc3m.es
Cc: pgsql-performance@postgresql.org
Subject: Re: general PG network slowness (possible cure) (repost)
References: <200705251344.l4PDibQ00402@inv.it.uc3m.es>
In-Reply-To: <200705251344.l4PDibQ00402@inv.it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter T. Breuer wrote:
> 
> The only operations being done are simple "find the row with this key",
> or "update the row with this key". That's all. The queries are not an
> issue (though why the PG thread choose to max out cpu when it gets the
> chance to do so through a unix socket, I don't know).

> There is no disk as such...  it's running on a ramdisk at the server
> end.  But assuming you mean i/o, i/o was completely stalled.  Everything
> was idle, all waiting on the net.

> Indeed, it is single, because that's my application. I don't have 
> 50 simultaneous connections.  The use of the database is as a permanent
> storage area for the results of previous analyses (static analysis of
> the linux kernel codes) from a single client.

>> I'm not sure your setup is typical, interesting though the figures are. 
>> Google a bit for pg_bench perhaps and see if you can reproduce the 
>> effect with a more typical load. I'd be interested in being proved wrong.
> 
> But the load is typical HERE. The application works well against gdbm
> and I was hoping to see speedup from using a _real_ full-fledged DB
> instead.

I'm not sure you really want a full RDBMS. If you only have a single 
connection and are making basic key-lookup queries then 90% of 
PostgreSQL's code is just getting in your way. Sounds to me like gdbm 
(or one of its alternatives) is a good match for you. Failing that, 
sqlite is probably the next lowest-overhead solution.

Of course, if you want to have multiple clients interacting and 
performing complex 19-way joins on gigabyte-sized tables with full-text 
indexing and full transaction control then you *do* want a RDBMS.

-- 
   Richard Huxton
   Archonet Ltd