From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: why postgresql is so slow? |
Date: | 2003-09-20 13:54:34 |
Message-ID: | m3ekybd0px.fsf@wolfe.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff <jdavis-pgsql(at)empires(dot)org> wrote:
> Then run "VACUUM ANALYZE" every once in a while (depending on how
> fast your data changes), like every night for instance.
Consider VACUUM and ANALYZE somewhat separately.
You need to ANALYZE any time the distribution of the data changes.
You need to VACUUM any time a lot of data is invalidated by UPDATEs or
DELETEs. (And when you VACUUM, it's cheap to throw in an ANALYZE.)
That turns into a variety of policies depending on what the pattern of
activity for a particular table is:
- If a table only ever gets INSERTs, you need only ever ANALYZE it,
as VACUUM should be useless. (Caveat: If INSERTs could get
rolled back due to other processing nuking transactions, that
leaves dead tuples for VACUUM to work with...)
- A table that sees enormous numbers of updates (for instance, a list
of account balances) should be vacuumed REALLY frequently.
- Any time you do a VACUUM, you might as well also do an ANALYZE.
pg_autovacuum applies these policies, so it's a reasonable thing to
use in 7.3/7.4...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/
"One of the most dangerous things in the universe is an ignorant
people with real grievances. That is nowhere near as dangerous,
however, as an informed and intelligent society with grievances. The
damage that vengeful intelligence can wreak, you cannot even imagine."
-- Miles Teg, Heretics of Dune
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-20 14:42:05 | Re: semtimedop instead of setitimer/semop/setitimer |
Previous Message | Gaetano Mendola | 2003-09-20 11:12:04 | Re: PostgreSQL not ACID compliant? |