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

From: "Peter T(dot) Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es>
To: "Richard Huxton" <dev(at)archonet(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: general PG network slowness (possible cure) (repost)
Date: 2007-05-25 14:02:21
Message-ID: 200705251402.l4PE2LN01473@inv.it.uc3m.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next 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))
Previous Message Alvaro Herrera 2007-05-25 13:56:52 Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13))