On Fri, 30 Nov 2007 16:48:24 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> > On Nov 30, 2007 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> AFAICS we are moving as fast as we can in the direction of auto
> >> vacuum and analyze. Adding more frammishes to the manual commands
> >> seems like gilding the buggy whip.
>
> 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.
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.
Autovacuum is a great utility for many workloads but even with the
upcoming changes I will continually find myself turning off autovacuum
for specific relations just so I can turn around and turn on vacuum
within cron for others.
The multi-worker autovacuum is a great new addition to help part of
that problem (starvation) but it is not help against the other
(resource consumption, specifically IO).
> I can see a need for manual vacuuming of
> individual special-case tables, but I don't see why schema-wide
> vacuuming is so useful as to justify diverting development effort to
> it.
The thing is, it isn't nearly as special case for my environments. I
have many customers, with many tables where autovacuum just doesn't cut
it. We turn it on for say 80% of the relations but guess what... the
important relations are still on some type of schedule through
something like cron.
I get your argument but surely adding SCHEMA isn't that much of a code
bloat scenario. We don't even have to add another reserved word...
Sincerely,
Joshua D. Drake
