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

Re: Enhancement request

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Campbell, Lance" <lance(at)uiuc(dot)edu>, "posgres support" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Enhancement request
Date: 2007-12-01 03:20:40
Message-ID: dcc563d10711301920g19c7deads732cd6044d636b8e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Nov 30, 2007 4:53 PM, Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> wrote:
> On Nov 30, 2007 5:00 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> > > So: show me a use case for this that will still make sense in a
> > > mostly-autovacuum world.
> >
> > I think you are living in a different world than I am if you think it
> > is a mostly-autovacuum world.
>
> Same here.
>
> > Yes autovacuum is great for general low use scenarios. Throw it at a
> > database doing hundreds of thousands (or even millions) of transactions
> > an hour that has relations that in the multiple hundred gig range and
> > autovacuum is useless for a good portion of that database.
>
> Yes, this is precisely the case I'm talking about.  Every single
> high-volume client we have or have consulted for is using custom
> vacuuming.  Autovacuum works fine for the common case, but it doesn't
> handle high-volume databases very well yet.

That's the case today, because autovacuum is single threaded and can't
hit >1 table at once, so a single very large table vacuum could allow
other, smaller tables to bloat inordinately.

Which is why 8.3 can vacuum > 1 table at a time.

I'm not against having a schema keyword mind you, I'm just pointing
out that the ultimate goal of the hackers seems to be an autovacuum
daemon that can keep the database vacuumed without the need for user
initiated vacuums at all.

Not sure 8.3 will get us there.  But the multi-threaded autovac is a
darn good start.

In response to

pgsql-admin by date

Next:From: Tom LaneDate: 2007-12-01 03:44:18
Subject: Re: Enhancement request
Previous:From: Jonah H. HarrisDate: 2007-12-01 00:32:31
Subject: Re: Enhancement request

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