From: | Guy Thornley <guy(at)esphion(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Vacuum I/O throttling |
Date: | 2003-09-01 23:48:59 |
Message-ID: | 20030901234859.GB25592@conker.esphion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Sep 01, 2003 at 09:05:33AM -0400, Tom Lane wrote:
> Guy Thornley <guy(at)esphion(dot)com> writes:
> > Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> > boxen arnt killed for hours a day when VACUUM runs.
>
> Wasn't this idea tried and rejected already? You haven't given us any
> information about actual performance.
I don't know, sorry; when I looked at the archives I only saw posts about
tuning vacuums, memory usage, etc, and people griping about the way it nukes
the I/O system. I'm new here.
What sort of performance numbers are you looking for? Without the throttle,
I/O is nuked and other database activity takes an age, and with it, its much
happier?
More seriously, this patch isnt meant to actually deal with vacuumed tuples.
The application being developed by the company I am working for requires
24x7x365 unattended operation. Even if vacuum ran every 6 months, for the
transaction renumbering stuff, the way it nukes I/O is not acceptable.
Especially on (potentially) several-hundred gig databases.
We are beginning to learn that "DBMS" and "unattended" dont belong in the
same sentence.
> > The usleep() could be replaced with a select() call with a timeout an no
> > fd_set's to aid portability..
>
> usleep is not portable, AFAIR.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bupp Phillips | 2003-09-02 01:28:47 | Re: session variable |
Previous Message | Stacy White | 2003-09-01 20:34:11 | to_timestamp not stable if date string shorter than template |