From: | Ian FREISLICH <if(at)hetzner(dot)co(dot)za> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Cc: | Steve <steve(at)hotmail(dot)com> |
Subject: | Re: please please please PLEASE help! |
Date: | 2004-07-30 12:59:01 |
Message-ID: | E1BqWyT-000Oqe-00@hetzner.co.za |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Rob Bamber" wrote:
> Another thought -
>
> We had a similar issue recently. Our support guys dropped the
> database and then rebuilt it from a dump file. The size of the data
> directory went down from 12GB to less than 2GB. According to the sys
> ad that did the work postgres is not very good a reclaiming disk space
> after large quantities of tuples are deleted over time.
And another thought,
Have you tried clustering your tables on the most frequently used
and/or time-important index in your joins? (remember to VACUUM
ANALYZE after the cluster has completed) You might find a huge
performance increase. Clustering should also fix the problem
mentioned above because the table is physically re-written on disk.
Use EXPLAIN ANALYZE to find out which is the most time-consuming
part of your query and optimise that.
Also, have you analyzed your database recently? If you've never
run VACUUM ANALYZE your query planner's statistics have never been
updated so the query planner might not be making the best choices.
Ian
--
Ian Freislich
From | Date | Subject | |
---|---|---|---|
Next Message | LISTMAN | 2004-07-30 13:33:05 | Where does the xlateSqlType symbol point to? |
Previous Message | Daniel Struck | 2004-07-30 09:43:31 | Re: [ADMIN] Secure DB Systems - How to |