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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Stephen" <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
