Re: Pet Peeves?

On Tue, Feb 3, 2009 at 9:27 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Mon, 2009-02-02 at 22:48 +0000, Gregory Stark wrote:
>> Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
>>
>> > - Managing jobs (e.g. - "pgcron")
>>
>> A number of people have mentioned a job scheduler. I think a job scheduler
>> entirely inside Postgres would be a terrible idea.
>
> You probably should explain why you think that rather than just rule it
> out, though I don't think we should be editing what people ask for.

Sorry, I was even the one who said this should be an open invitation to gripe.

The point I was making is that the original proposal could be
interpreted to mean two different things. One of which I think is an
actively bad idea and one of which I think is actually a good idea. I
also didn't mean to imply Christopher meant one or the other -- sorry.

> We already have autovacuum, which runs VACUUM and ANALYZE to a set
> schedule. We could have kept that outside core, but didn't.
>
> It's not too big a stretch to imagine we could redesign autovacuum as a
> GP scheduler, with autovacuum as just one/two regular scheduled jobs.

Except autovacuum *isn't* a regularly scheduled job and doesn't run
vacuum and analyze on a set schedule. It runs them on a highly dynamic
schedule based on observations of activity in the database. It also
has privileged access to the database, reading from all databases and
receiving signals when various events occur. You cannot implement
autovacuum's current behaviour in cron no matter how clever you make
cron.

A client reimplementing cron using the database as a backend would be
a nice database-driven tool, not just for DBAs but for anyone needing
a more flexible cron demon. It wouldn't even have to be
Postgres-specific, any SQL database would surely be sufficient for the
job. If I were writing it I would start in Perl but I hear the kids
these days are all doing Python or Ruby or something.

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.

As I said, I don't know which Christopher was thinking of, apparently
not the latter based on his subsequent response. But in case anyone
else was or simply hadn't realized there were two different
conceptions of this I wanted to draw the distinction.

--
greg