Re: Automatic free space map filling
От | Simon Riggs |
---|---|
Тема | Re: Automatic free space map filling |
Дата | |
Msg-id | 1146566074.9599.350.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Automatic free space map filling (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
On Fri, 2006-04-28 at 15:58 -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Alvaro Herrera <alvherre@commandprompt.com> 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
В списке pgsql-hackers по дате отправления: