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

Re: Experimental patch for inter-page delay in VACUUM

From: "Stephen" <jleelim(at)xxxxxxx(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-02 05:45:08
Message-ID: GQ0pb.5642$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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

Regards, Stephen

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
> "Stephen" <jleelim(at)xxxxxx(dot)com> writes:
> > also as there are less processes waiting to complete. I find a value of
> > to 5ms is quite good and will keep system responsive. Going from 10ms to
> > didn't seem to reduce the total vacuum time by much and I'm not sure
> 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?

In response to


pgsql-hackers by date

Next:From: Stephan SzaboDate: 2003-11-02 05:58:00
Subject: Re: Getting number of matched records from query
Previous:From: Michael OwensDate: 2003-11-02 04:54:05
Subject: Getting number of matched records from query

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