On Wed, Nov 12, 2008 at 9:27 AM, - - <themanatuf@yahoo.com> wrote:
> I've been searching for performance metrics and tweaks for a few weeks now.
> I'm trying to determine if the length of time to process my queries is
> accurate or not and I'm having a difficult time determining that. I know
> postgres performance is very dependent on hardware and settings and I
> understand how difficult it is to tackle. However, I was wondering if I
> could get some feedback based on my results please.
>
> The database is running on a dual-core 2GHz Opteron processor with 8GB of
> RAM. The drives are 10K RPM 146GB drives in RAID 5 (I've read RAID 5 is bad
> for Postgres, but moving the database to another server didn't change
> performance at all). Some of the key parameters from postgresql.conf are:
I'm not sure what you mean. Did you move it to another server with a
single drive? A 100 drive RAID-10 array with a battery backed caching
controller? There's a lot of possibility in "another server".
>
> max_connections = 100
> shared_buffers = 16MB
WAY low. try 512M to 2G on a machine that big.
> work_mem = 64MB
acceptable. For 100 clients, if each did a sort you'd need 6.4Gig of
free ram, but since the chances of all 100 clients doing a sort that
big at the same time are small, you're probably safe.
>
> One of my tables has 660,000 records and doing a SELECT * from that table
> (without any joins or sorts) takes 72 seconds. Ordering the table based on 3
> columns almost doubles that time to an average of 123 seconds. To me, those
How wide is this table? IF it's got 300 columns, then it's gonna be a
lot slower than if it has 10 columns.
Try running your query like this:
\timing
select count(*) from (my big query goes here) as a;
and see how long it takes. This will remove the network effect of
transferring the data. If that runs fast enough, then the real
problem is that your client is waiting til it gets all the data to
display it.