From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | shridhar_daithankar(at)persistent(dot)co(dot)in |
Cc: | PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Auto Vacuum Daemon (again...) |
Date: | 2002-12-10 14:05:27 |
Message-ID: | 1039476395.21023.8.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2002-11-29 at 07:19, Shridhar Daithankar wrote:
> On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
>
> > On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
> > > On 28 Nov 2002 at 10:45, Tom Lane wrote:
> > > > This is almost certainly a bad idea. vacuum is not very
> > > > processor-intensive, but it is disk-intensive. Multiple vacuums running
> > > > at once will suck more disk bandwidth than is appropriate for a
> > > > "background" operation, no matter how sexy your CPU is. I can't see
> > > > any reason to allow more than one auto-scheduled vacuum at a time.
> > > Hmm.. We would need to take care of that as well..
> > Not sure what you mean by that, but it sounds like the behaviour of my AVD
> > (having it block until the vacuum command completes) is fine, and perhaps
> > preferrable.
>
> Right.. But I will still keep option open for parallel vacuum which is most
> useful for reusing tuples in shared buffers.. And stale updated tuples are what
> causes performance drop in my experience..
>
> You know.. just enough rope to hang themselves..;-)
>
Right. This is exactly what I was thinking about. If someone shoots
their own foot off, that's their problem. The added flexibility seems
well worth it.
Greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-10 14:34:40 | Re: Let's create a release team |
Previous Message | Greg Copeland | 2002-12-10 14:04:55 | Re: Auto Vacuum Daemon (again...) |