From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Vaccum Stalling |
Date: | 2007-07-10 15:17:49 |
Message-ID: | 19904.1184080669@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> writes:
> Scenario - a large table was not being vacuumed correctly, there now ~
> 15 million dead tuples that account for approximately 20%-25% of the
> table. Vacuum appears to be stalling - ran for approximately 10 hours
> before I killed it. I hooked up to the process with gdb and this looks
> a bit suspicious to me.
Looks perfectly normal to me. Reads in btbulkdelete are exactly where
I'd expect 7.4's vacuum to be spending the bulk of its wait time on a
large table, because that's a logical-order traversal of the index, and
cannot benefit from any sequential-access advantage. (As of 8.2 we
are able to do this with a physical-order traversal, which can be a
whole lot faster.)
If you can afford to lock the table against writes for awhile,
reindexing might help by bringing the index back into physical order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Raymond O'Donnell | 2007-07-10 15:17:51 | Re: [GENERAL] pgpass.conf |
Previous Message | Kevin martins | 2007-07-10 15:13:50 | Problems with linkage |