Skip site navigation (1) Skip section navigation (2)

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

From: Richard Huxton <dev(at)archonet(dot)com>
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 13:52:34
Message-ID: 4656EA22.4020801@archonet.com (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Alvaro HerreraDate: 2007-05-25 13:56:52
Subject: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))
Previous:From: Peter T. BreuerDate: 2007-05-25 13:44:37
Subject: Re: general PG network slowness (possible cure) (repost)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group