From: "Peter T. Breuer" <ptb@inv.it.uc3m.es>
Message-Id: <200705251402.l4PE2LN01473@inv.it.uc3m.es>
Subject: Re: general PG network slowness (possible cure) (repost)
In-Reply-To: <4656EA22.4020801@archonet.com> from "Richard Huxton" at "May 25,
	2007 02:52:34 pm"
To: "Richard Huxton" <dev@archonet.com>
Date: Fri, 25 May 2007 16:02:21 +0200 (MET DST)
CC: pgsql-performance@postgresql.org
Reply-To: ptb@inv.it.uc3m.es
Reply-By: Sat, 1 Apr 2006 14:21:08 -0700

"Also sprach Richard Huxton:"
> 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 

Yep - I could happily tell it not to try and compile a special lookup
scheme each time, for example!  (how that?). I could presumably also
help it by preloading the commands I will run and sending over the 
params only with a "do a no. 17 now!".

> (or one of its alternatives) is a good match for you. Failing that, 
> sqlite is probably the next lowest-overhead solution.

Not a bad idea. but PG _will_ be useful when folk come to analyse the
result of the analyses being done. What is slow is getting the data
into the database now via simple store, fetch and update.

> Of course, if you want to have multiple clients interacting and 
> performing complex 19-way joins on gigabyte-sized tables with full-text 

Well, the dbs are in the tens of MB from a single run over a single
file (i.e analysis of a single 30KLOC source).  The complete analysis
space is something like 4000 times that, for 4300 C files in the linux
kernel source. And then there is all the linux kernel versions. Then
there is godzilla and apache source ..

> indexing and full transaction control then you *do* want a RDBMS.

We want one anyway. The problem is filling the data and the simple
fetch and update queries on it.

I really think it would be worthwhile getting some developer to tell me
where the network send is done in PG.

Peter