Re: Enhancement request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 30, 2007 4:53 PM, Jonah H. Harris <jonah.harris@xxxxxxxxx> wrote:
> On Nov 30, 2007 5:00 PM, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx> 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.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux