Re: Experimental patch for inter-page delay in VACUUM

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" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
>news:2254(dot)1067713969(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
>
>
>>"Stephen" <jleelim(at)xxxxxx(dot)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
>>
>>
>>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>
>