On Fri, 2006-04-28 at 15:58 -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > So for you it would certainly help a lot to be able to vacuum the first > > > X pages of the big table, stop, release locks, create new transaction, > > > continue with the next X pages, lather, rinse, repeat. > > > > > This is perfectly doable, it only needs enough motivation from a > > > knowledgeable person. > > > > Bruce and I were discussing this the other day; it'd be pretty easy to > > make plain VACUUM start a fresh transaction immediately after it > > finishes a scan heap/clean indexes/clean heap cycle. The infrastructure > > for this (in particular, session-level locks that won't be lost by > > closing the xact) is all there. You'd have to figure out how often to > > start a new xact ... every cycle is probably too often, at least for > > smaller maintenance_work_mem settings ... but it'd not be hard or > > involve any strange changes in system semantics. > > Should this be a TODO? One item of discussion was taht people should > just increase their workmem so the job can be done faster in larger > batches.
Yes, I think it should be a todo item. Csaba's point was that it was the duration a VACUUM transaction was held open that caused problems. Increasing maintenance_work_mem won't help with that problem. This would then allow a VACUUM to progress with a high vacuum_cost_delay without any ill effects elsewhere in the system. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
