From: | aturner(at)neteconomist(dot)com |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Upgrade Woes |
Date: | 2003-09-11 19:10:18 |
Message-ID: | 20030911191018.GA11764@neteconomist.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
In the performance case the machine was running RedHat AS 2.1. I have posted the database schema at (obtained from pg_dump -s):
http://serverbeach.plexq.com/~aturner/schema.sql
The time to run all the stats procedures dropped through the floor. refresh_hourly_iud, adl_hourly_iud, rebuild_daily_total etc. There is a python script that calls the proc once for each hour or day. When running the historical calc job for a 7 day period back, it would crawl on 7.3.3. We started benching the drive array and found other issues with the system in the mean time (like the drive array was giving us 10MB/sec write speed - the guy who set it up did not enable write to cache). Once it was reconfigured the DB performance did not improve much (bonnie++ was used to verify the RAID array speed).
Alex Turner
On Thu, Sep 11, 2003 at 11:47:32AM -0400, Tom Lane wrote:
> aturner(at)neteconomist(dot)com writes:
> > As for 7.3.3, the project in question suffered a 10x performance
> > degredation on 7.3.3 which went away when we rolled back to 7.3.2.
>
> I would like to pursue that report and find out why. I've just gone
> through the CVS logs between 7.3.2 and 7.3.3, and I don't see any change
> that would explain a 10x slowdown. Can you provide more details about
> exactly what slowed down?
>
> Also, what PG version were you using on the old RedHat 7.2 installation?
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Jones | 2003-09-12 10:26:29 | best arrangement of 3 disks for (insert) performance |
Previous Message | Christopher Browne | 2003-09-11 16:32:01 | Re: [GENERAL] how to get accurate values in pg_statistic |