On Tue, Feb 3, 2009 at 9:27 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Mon, 2009-02-02 at 22:48 +0000, Gregory Stark wrote: >> Christopher Browne <cbbro...@gmail.com> writes: >> >> > - Managing jobs (e.g. - "pgcron") >> >> A number of people have mentioned a job scheduler. I think a job scheduler >> entirely inside Postgres would be a terrible idea. > > You probably should explain why you think that rather than just rule it > out, though I don't think we should be editing what people ask for.
Sorry, I was even the one who said this should be an open invitation to gripe. The point I was making is that the original proposal could be interpreted to mean two different things. One of which I think is an actively bad idea and one of which I think is actually a good idea. I also didn't mean to imply Christopher meant one or the other -- sorry. > 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. A client reimplementing cron using the database as a backend would be a nice database-driven tool, not just for DBAs but for anyone needing a more flexible cron demon. It wouldn't even have to be Postgres-specific, any SQL database would surely be sufficient for the job. If I were writing it I would start in Perl but I hear the kids these days are all doing Python or Ruby or something. My only point was that this would be very different from Oracle-style job scheduler implemented *inside* the database using database-specific code and requiring database-specific code to interact with the outside world. That's just reimplementing the whole world using the database as a weird operating system which is someone else's game. As I said, I don't know which Christopher was thinking of, apparently not the latter based on his subsequent response. But in case anyone else was or simply hadn't realized there were two different conceptions of this I wanted to draw the distinction. -- greg -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
