From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Guy Rouillier <guyr-ml1(at)burntmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Pet Peeves? |
Date: | 2009-02-04 04:01:50 |
Message-ID: | dcc563d10902032001ie6e87e7s7fa3e9ad82864bd4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Feb 3, 2009 at 8:58 PM, Guy Rouillier <guyr-ml1(at)burntmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-02-04 04:14:11 | Re: Pet Peeves? |
Previous Message | Guy Rouillier | 2009-02-04 03:58:19 | Re: Pet Peeves? |