On Tue, 27 Jun 2006, Jim Nasby wrote:
What the heck? Why would it have shrunk down so much? The vacuum full
isn't scheduled until tonight. :-/
Take a look at the source for autovacuum... I'm guessing you're right and
that it doesn't make any special considerations for toast tables, which it
probably should (since AFAIK you have to first vacuum the base table, then
commit, then vacuum the toast table).
BTW, tracking pg_class.relpages or actual file size over time would probably
be helpful.
Actually, it says this:
/*
* Scan pg_class and determine which tables to vacuum.
*
* The stats subsystem collects stats for toast tables independently of
* the stats for their parent tables. We need to check those stats since
* in cases with short, wide tables there might be proportionally much
* more activity in the toast table than in its parent.
*
* Since we can only issue VACUUM against the parent table, we need to
* transpose a decision to vacuum a toast table into a decision to vacuum
* its parent. There's no point in considering ANALYZE on a toast table,
* either. To support this, we keep a list of OIDs of toast tables that
* need vacuuming alongside the list of regular tables. Regular tables
* will be entered into the table list even if they appear not to need
* vacuuming; we go back and re-mark them after finding all the vacuumable
* toast tables.
*/
So I guess it does take toast tables into account.
--
Jeff Frost, Owner <[EMAIL PROTECTED]>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
