On Fri, 30 Nov 2007 16:48:24 -0500 Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > "Jonah H. Harris" <jonah.harris@xxxxxxxxx> writes: > > On Nov 30, 2007 4:30 PM, Tom Lane <tgl@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
