As it turns out. With vacuum_page_delay = 0, VACUUM took 1m20s (80s) to
complete, with vacuum_page_delay = 1 and vacuum_page_delay = 10, both
VACUUMs completed in 18m3s (1080 sec). A factor of 13 times! This is for a
single 350 MB table.
Apparently, it looks like the upcoming Linux kernel 2.6 will have a smaller
quantum:
http://go.jitbot.com/linux2.6-quantum
There is also mention of user-space tweak to get a more accurate time slice
of near 1ms on Linux, but I'm not sure how this works and if it applies to
Unixes:
http://go.jitbot.com/linux-devrtc-quantum
Regards, Stephen
"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:2254.1067713969@sss.pgh.pa.us...
> "Stephen" <jleelim@xxxxxx.com> writes:
> > also as there are less processes waiting to complete. I find a value of
1ms
> > to 5ms is quite good and will keep system responsive. Going from 10ms to
1ms
> > didn't seem to reduce the total vacuum time by much and I'm not sure
why.
>
> On most Unixen, the effective resolution of sleep requests is whatever
> the scheduler time quantum is --- and 10ms is the standard quantum in
> most cases. So any delay less than 10ms is going to be interpreted as
> 10ms.
>
> I think on recent Linuxen it's possible to adjust the time quantum, but
> whether this would be a net win isn't clear; presumably a shorter
> quantum would result in more scheduler overhead and more process-swap
> penalties.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>