Re: Some thoughts about i/o priorities and throttling vacuum
От | Stephen |
---|---|
Тема | Re: Some thoughts about i/o priorities and throttling vacuum |
Дата | |
Msg-id | 57Kjb.18$PO4.4@nntp-post.primus.ca обсуждение исходный текст |
Ответ на | Re: Some thoughts about i/o priorities and throttling vacuum (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
Is it possible to have an optional delay in plain VACUUM for each invocation rather than database wide? Something along the line of an optional THROTTLE or DELAY parameter for the VACUUM command. The THROTTLE is ignored when FULL or FREEZE is selected. VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [THROTTLE] ANALYZE [ table [ (column [, ...] ) ] ] This way autovacuum can still throttle VACUUM as needed in future (either in contrib or backend) and administrators can decide to apply different delays for different tables depending on the usage. Regards, Stephen "Tom Lane" <tgl@sss.pgh.pa.us> wrote in message news:16916.1066349859@sss.pgh.pa.us... > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Of course, this makes VACUUM run longer, and if you are waiting for it > > to finish, it would be worse, like if you are running it at night or > > something. > > I think the delay has to take into account the number of active > > transactions or something. > > I was just thinking of a GUC parameter: wait N milliseconds between > pages, where N defaults to zero probably. A user who wants to run his > vacuum as a background process could set N larger than zero. I don't > believe we are anywhere near being able to automatically adjust the > delay based on load, and even if we could, this would ignore the point > you make above --- the user's intent has to matter as much as anything > else. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
В списке pgsql-hackers по дате отправления: