We have a frequently updated (peak 5/sec) table with about 1000 rows.
We run VACCUM FULL on this table every 5 minutes.
The regular updates are not long in duration, and the vacuum is fast, so they
do not produce noticeable delays.
When we run a pg_dump on the database:
- the dump takes a long
On Sun, Jan 30, 2005 at 01:23:11 +1100,
Philip Warner [EMAIL PROTECTED] wrote:
We have a frequently updated (peak 5/sec) table with about 1000 rows.
We run VACCUM FULL on this table every 5 minutes.
Why not just use plain VACUUM? The table will reach a steady state size.
You should only
Philip Warner [EMAIL PROTECTED] writes:
We have a frequently updated (peak 5/sec) table with about 1000 rows.
We run VACCUM FULL on this table every 5 minutes.
I agree with Bruno's comment that you shouldn't be doing that in the
first place. Plain vacuum (perhaps executed even more often,
Philip Warner [EMAIL PROTECTED] writes:
Am I correct in saying that the FSM now tracks the entire table, and that
the FSM parameters just determine how much is stored in memory?
No. Any free space that can't be remembered in FSM is lost to use.
(Not completely --- an update of a row on the
