On Tue, Feb 3, 2009 at 8:58 PM, Guy Rouillier <guyr-ml1@burntmail.com> wrote:
> 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.
Yep, this allows enough separation from OS and db that I can give
users permission to schedule jobs in the db without needing to have an
account on my db server or a cronjob connection remotely and
anonymously from who knows what machine.
