Re: Some thoughts about i/o priorities and throttling vacuum

From: "Stephen" <jleelim(at)xxxxxx(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Some thoughts about i/o priorities and throttling vacuum
Date: 2003-10-16 06:01:13
Message-ID: Quqjb.9348$uP4.6602@nntp-post.primus.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:16818(dot)1066282922(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> Greg Stark <gsstark(at)mit(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Swan 2003-10-16 07:07:02 Re: postgres --help-config
Previous Message Tom Lane 2003-10-16 05:59:48 Re: Still a few flaws in configure's default CFLAGS selection