Greg Stark wrote:
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.
And someone else might want to play that game inside PG ;). Seriously, we already have programs running inside the DB (stored procs), so why not jobs? I can think of several useful applications. I have an application with a high volume of inserts (60M + per day). Maybe I can conceive of some way to reorganize the previous day's data at 2 am each morning that will provide much better performance. Since all that activity is inside the database, why not schedule it inside the DB also? It's the same logic to justify stored procs.
Sure, I can accomplish the same thing via cron and external scripts. But that's less secure, since I need to store my connection params in the script. And if I've got 5 different servers running cron jobs, then my schedule is distributed over those 5 boxes, which becomes a management issue. As has been pointed out here, the schedule could be kept in the DB, which would address that. Having a scheduler in the DB to run those jobs is just the next step.
Different stokes, as they say. All about choice. -- Guy Rouillier -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
