On Wed, 2009-02-04 at 03:00 +0000, Greg Stark wrote:
> We already have autovacuum, which runs VACUUM and ANALYZE to a set
> > schedule. We could have kept that outside core, but didn't.
> >
> > It's not too big a stretch to imagine we could redesign autovacuum
> as a
> > GP scheduler, with autovacuum as just one/two regular scheduled
> jobs.
>
> Except autovacuum *isn't* a regularly scheduled job and doesn't run
> vacuum and analyze on a set schedule. It runs them on a highly dynamic
> schedule based on observations of activity in the database. It also
> has privileged access to the database, reading from all databases and
> receiving signals when various events occur. You cannot implement
> autovacuum's current behaviour in cron no matter how clever you make
> cron.
So putting a scheduler inside the database allows it to do things it
couldn't otherwise do. Sounds like a great argument for *inclusion*.
AV runs every (configurable) 60 secs. What it does when it runs is its
own business. It has a pool of slaves ready to do real transactional
work and an infrastructure to preferentially cancel work if it
interferes with users. It's clearly a great place to hang other code
that (somebody) would like to run on a regular basis:
* regular maintenance tasks
* performance tuning
* summary table creation/maintenance
* adding partitions
* health checks
* etc
We can keep adding processes every time we want a new function in the
db, or we can add a generic facility. I've already added two special
processes, so I'd rather not add too many more.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support