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
