poor performance of db? - Mailing list pgsql-performance

From SpaceBallOne
Subject poor performance of db?
Date
Msg-id BAY14-DAV850511937A7C1DDE0806FCC850@phx.gbl
Whole thread Raw
Responses Re: poor performance of db?
Re: poor performance of db?
Re: poor performance of db?
List pgsql-performance
Hello everyone,

First time poster to the mailing list here.
 
We have been running pgsql for about a year now at a pretty basic level (I guess) as a backend for custom web (intranet) application software. Our database so far is a "huge" (note sarcasm) 10 Mb containing of about 6 or so principle tables. 
 
Our 'test' screen we've been using loads a 600kb HTML document which is basically a summary of our client's orders. It took originally 11.5 seconds to load in internet explorer (all 10.99 seconds were pretty much taken up by postgres processes on a freebsd server).
 
I then re-wrote the page to use a single select query to call all the information needed by PHP to draw the screen. That managed to shave it down to 3.5 seconds... but this so far is as fast as I can get the page to load. Have tried vacuuming and creating indexes but to no avail. (increasing shared mem buffers yet to be done)
 
Now heres the funny bit ...

Every time I tested an idea to speed it up, I got exactly the same loading time on a Athlon 1800+, 256Mb RAM, 20Gb PATA computer as compared to a Dual Opteron 246, 1Gb RAM, 70Gb WD Raptor SATA server. Now, why a dual opteron machine can't perform any faster than a lowly 1800+ athlon in numerous tests is completely beyond me .. increased memory and RAID 0 disc configurations so far have not resulted in any significant performance gain in the opteron server.
 
Do these facts sound right? If postgres is meant to be a 200Gb industrial strength database, should it really be taking this long pulling 600kb worth of info from a 10Mb database? And why no performance difference between two vastly different hardware spec'd computers??? Am I missing some vital postgres.conf setting??

Any advice welcome.

Thanks,
Dave
 

pgsql-performance by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering
Next
From: Simon Riggs
Date:
Subject: Faster and more frequent VACUUM (was PostgreSQL clustering VS MySQL clustering)