I have many such tasks. Depending on implementation, it has the potential
to be a TINY amount of less work to schedule such tasks from inside
the database, but it takes all of about a minute to schedule it through
cron. Including the amount of time it takes to refer to the man page.
Additionally, cron has already been written and is already maintained,
neither of which is true about an internal postgres scheduler.
I suppose I can see the point of needing a scheduler in postgres if you
don't give your DBAs access to cron, but from my point of view (for
whatever that's worth), giving your DBAs access to cron seems like a small
price to pay for an elegant database design.
On Fri, 17 Dec 2004, Guy Rouillier wrote:
> Here is a real world example where a scheduler in PostgreSQL would be
> helpful. We collect usage statistics from our network throughout the
> day (raw stats.) After midnight, we roll up those raw stats into daily
> statistics.
> We have a very large amount of data, about 2 million rows a day a
> growing, so I want this whole operation done on the database server.
> It's all database work, just summing up data from one table and putting
> the result in another table. We have all that logic in a stored
> procedure. So why do I need to set up a cron job and a shell script
> whose only task is to connect to the database and start up the stored
> procedure? Wouldn't it be much simpler just to have a schedule in
> PostgreSQL that says "at 12:01, run this stored procedure"?
>
> Another advantage to having a scheduler in the database is to ease your
> DBA's job in maintenance, and to coordinate work by multiple systems.
>
> --
> Guy Rouillier
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>