On Tue, 2005-04-05 at 02:42, Tom Lane wrote:
> "Ian Westmacott" <ianw@intellivid.com> writes:
> > The problem is that we are writing rows every 1/15 second, 24x7. There
> > is no down time. I'm wondering if there is any way to avoid vacuuming
> > the old tables over and over. The documentation seems to indicate that
> > a full vacuum is needed to avoid XID wrap-around. Can vacuum freeze
> > help me?
>
> VACUUM FULL isn't really relevant. VACUUM FREEZE on a particular table
> should "fix" that table permanently, as long as you don't make any more
> changes to it. Keep in mind though that you still have to vacuum the
> system catalogs often enough to avoid wraparound in them. The real risk
> here is in overlooking any one table. You should probably use some kind
> of automated vacuum driver ... have you looked at pg_autovacuum?
We did look at pg_autovacuum. We found the cost of row-
level statistics too high to be workable. Looking at the
pg_autovacuum code, it appears that a full vacuum is
performed whenever the XIDs get old enough. The problem
is that it is unpredictable when this will occur.
So we have started work on our own automated driver,
primarily for the analyze side of things at the moment,
but I would like to extend it to vacuum as well. For
example, we could update the row-level statistics on a
less frequent basis than every insert.
But the question is whether vacuum freezing tables will
help me reduce the frequency of a full vacuum, or reduce
its cost when we do it? That is, if more transactions
are frozen, will a full vacuum be more efficient
(primarily in the I/O)?
> I believe Fujitsu is looking into what it'd take to make a variant
> Postgres with 64-bit XIDs. This'd probably imply also expanding CIDs,
> OIDs, and some other things, so the space penalty is not to be sneezed
> at ... but it might be worth it for installations like yours.
Thanks for the pointer, I'll take a look.
--Ian