I think adding tunable delay per-page loop into VACUUM will help keep system
responsive at all times. In many cases, especially for mostly read-only
tables, plain VACUUM does not need to complete immediately (VACUUM FULL
should complete immediately). I prefer that VACUUM takes its sweet time to
run as long as it doesn't disrupt other queries. See my other post on
"VACUUM degrades performance significantly. Database becomes unusable!" on
pgsql-general mailing list.
Regards,
Stephen
"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:16818.1066282922@sss.pgh.pa.us...
> Greg Stark <gsstark@mit.edu> writes:
> > ... vacuum could throttle
> > its own disk accesses by, say, reading 64k at a time then sleeping for
> > a fraction of a second.
> > ...
> > Personally I think i/o priorities give much better leverage.
>
> Pie in the sky is great too ;-). But there is no such thing as i/o
> priorities, at least not in any portable sense.
>
> OTOH I was just musing to myself earlier today that putting a tunable
> delay into VACUUM's per-page loop might make it more friendly to
> competing processes. I dunno if it'd work or just be a waste of time,
> but it does seem worth experimenting with.
>
> Want to try it out and report back?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>