Re: Vacuum I/O throttling

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

In response to

Responses

Browse pgsql-bugs by date

  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