Skip site navigation (1) Skip section navigation (2)

Re: Pet Peeves?

From: Guy Rouillier <guyr-ml1(at)burntmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Pet Peeves?
Date: 2009-02-04 03:58:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
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

In response to


pgsql-general by date

Next:From: Scott MarloweDate: 2009-02-04 04:01:50
Subject: Re: Pet Peeves?
Previous:From: Greg StarkDate: 2009-02-04 03:00:47
Subject: Re: Pet Peeves?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group