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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
