Re: [HACKERS] Experimental patch for inter-page delay in VACUUM

[Andrew Dunstan]

Not surprising, I should have thought. Why would you care that much?  
The idea as I understand it is to improve the responsiveness of things 
happening alongside vacuum ("real work"). I normally run vacuum when I 
don't expect anything else much to be happening - but I don't care how 
long it takes (within reason), especially if it isn't going to intefere 
with other uses.

cheers

andrew

Stephen wrote:

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
 



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match