Re: Some thoughts about i/o priorities and throttling vacuum
От
Matthew T. O'Connor
Тема
Re: Some thoughts about i/o priorities and throttling vacuum
Дата
Msg-id
1066336971.10302.9.camel@zeutrh9
Ответ на
Список
Дерево обсуждения
Re: Some thoughts about i/o priorities and throttling vacuum "Stephen" <jleelim@xxxxxx.com>
Re: Some thoughts about i/o priorities and throttling vacuum Bruce Momjian <pgman@candle.pha.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum "Matthew T. O'Connor" <matthew@zeut.net>
Re: Some thoughts about i/o priorities and throttling vacuum Andrew Sullivan <andrew@libertyrms.info>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum Andrew Sullivan <andrew@libertyrms.info>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Rod Taylor <rbt@rbt.ca>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum "Matthew T. O'Connor" <matthew@zeut.net>
Re: Some thoughts about i/o priorities and throttling vacuum Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
Re: Some thoughts about i/o priorities and throttling vacuum "Matthew T. O'Connor" <matthew@zeut.net>
Re: Some thoughts about i/o priorities and throttling vacuum Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Some thoughts about i/o priorities and throttling vacuum Tom Lane <tgl@sss.pgh.pa.us>
Re: Some thoughts about i/o priorities and throttling vacuum Greg Stark <gsstark@mit.edu>
Re: Some thoughts about i/o priorities and throttling vacuum "Matthew T. O'Connor" <matthew@zeut.net>
On Thu, 2003-10-16 at 16:16, Greg Stark wrote: > Bruce Momjian 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. > > My plan was that the time delay would be a parameter and pg_autovacuum would > set it based on the observed rate at which free space is accumulating. I don't know that pg_autovacuum is smart enough to make a good guess as to an appropriate parameter. > > I think the delay has to take into account the number of active > > transactions or something. I think this is a better plan than pg_autovacuum, this would also allow vacuum to have a different delay for each loop depending on the current number of transactions. > But vacuum has no way to judge whether those transactions are really doing > much disk i/o or only reading cached blocks, or even whether the disk i/o > they're doing is on the same disk. They could also be waiting on the client or > on locks from other transactions. True, it would be a rough estimate, but at least one based on something representative of system I/O load at that moment.
В списке pgsql-hackers по дате отправления