From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-11-04 17:52:13 |
Message-ID: | 8765i058du.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > vacuum_page_per_delay = 2
> > vacuum_time_per_delay = 10
>
> That's exactly what I did ... look at the combined experiment posted under
> subject "Experimental ARC implementation". The two parameters are named
> vacuum_page_groupsize and vacuum_page_delay.
FWIW this seems like a good idea for other reasons too, the hard drive and the
kernel are going to read multiple sequential blocks anyways whether you sleep
on them or not. Better to read enough blocks to take advantage of the
readahead without saturating the drive, then sleep to let those buffers age
out. If you read one block then sleep the buffers of readahead may get aged
out and have to be fetched again, which would actually increase the amount of
i/o bandwidth used.
I would expect much higher vacuum_page_per_delay's would probably not have a
noticable effect and be much faster. Something like
vacuum_page_per_delay = 128
vacuum_time_per_delay = 100
Or more likely, something in-between.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2003-11-04 17:58:33 | Re: 7.4RC1 tag'd, branched and bundled ... |
Previous Message | Christopher Browne | 2003-11-04 17:32:29 | RC1 on AIX - Some Anti-results |