From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Logan Bowers" <logan(at)datacurrent(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Neil Conway" <neilc(at)samurai(dot)com>, <sean(at)chittenden(dot)org>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: postgresql meltdown on PlanetMath.org |
Date: | 2003-03-18 02:44:01 |
Message-ID: | 088d01c2ecf8$3bf742e0$6500a8c0@fhp.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I'm running this db on a celeron 450Mhz with 256MB RAM and a 60GB HDD
> (7200 rpm). For the most part I have the db running "well enough." Over
> time however, I find that performance degrades, the count(*) above is an
> example of a command that does worse over time. It gets run once an hour
> for stats collection. When I first migrated the db to v7.3.1 it would
> take about 5-10 seconds (which it is close to now after a VACUUM FULL) but
> after a few weeks it would take over a minute of really intense HDD
> activity. Also of note is that when I first loaded the data it would
> cache very well with the query taking maybe taking 15 seconds if I had
> just started the db after reboot, but when it was in its "slow" state
> repeating the query didn't noticably use the disk less (nor did it take
> less time).
To speed up your COUNT(*), how about doing this:
Create a separate table to hold a single integer.
Add a trigger after insert on your table to increment the counter in the
other table
Add a trigger after delete on your table to decrement the counter in the
other table.
That way you always have an O(1) count...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-18 02:51:49 | Re: postgresql meltdown on PlanetMath.org |
Previous Message | Logan Bowers | 2003-03-18 02:41:07 | Re: postgresql meltdown on PlanetMath.org |