From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_autovacuum and VACUUM FREEZE |
Date: | 2003-10-16 16:22:38 |
Message-ID: | 1066321358.9691.18.camel@zeutrh9 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2003-10-16 at 10:16, Rod Taylor wrote:
> > The vacuum man page says, "FREEZE is not recommnded for routine use".
> > That was enough to keep me away. However if vacuum freeze was
> > considerably lighter than normal database wide vacuums then there might
> > be an advantage to using it. Especially since when pg_autovaccum
> > decides it's time to deal with xid wraparound, it does it to all the
> > databases, which could a several hours of vacuum on large clusters.
>
> Each database has it's own last xid. Just because one database is about
> to go over the limit doesn't mean they all are. Why don't you treat
> each database independently in this regard (then they wouldn't
> necessarily all be kicked off at once).
My choice of words above was poor, let me try again.
pg_autovacuum does treat each database independently, however assuming
that you never manually run vacuum (which is the eventual goal of
pg_autovacuum), then database wide vacuums will have never been run on
any table in any database, so all databases will approach xid wraparound
at the same time.
So, pg_autovacuum does deal with them separately, but doesn't make an
effort to spread out the vacuums if all / multiple databases happen to
need it at the same time.
In practice, I don't see this as a big problem right now, but it should
still be handled better by pg_autovacuum.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-10-16 16:54:46 | elog tab indentation |
Previous Message | Christopher Browne | 2003-10-16 14:31:45 | Re: Database Kernels and O_DIRECT |