Skip site navigation (1) Skip section navigation (2)

Re: Experimental patch for inter-page delay in VACUUM

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-02 21:20:50
Message-ID: 3FA57532.3020902@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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
>
>  
>


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-11-02 21:47:55
Subject: PlayStation 2 problems
Previous:From: Manfred SpraulDate: 2003-11-02 21:10:57
Subject: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group