From: Richard Huxton <dev@archonet.com>
To: ptb@inv.it.uc3m.es
Cc: pgsql-performance@postgresql.org
Subject: Re: general PG network slowness (possible cure) (repost)
Date: Fri, 25 May 2007 14:52:34 +0100
Message-ID: <4656EA22.4020801@archonet.com> (raw)
In-Reply-To: <200705251344.l4PDibQ00402@inv.it.uc3m.es>
References: <200705251344.l4PDibQ00402@inv.it.uc3m.es>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dev@archonet.com, ptb@inv.it.uc3m.es
Subject: Re: general PG network slowness (possible cure) (repost)
In-Reply-To: <4656EA22.4020801@archonet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox