It does sound nice,something like cron? We can use a scheduling algorithm, and can define a pool of tasks as well as a time constraint for the amount of time which can be used for running the tasks.Then, a scheduling algorithm can pick tasks from the pool based on priorities and the time duration of a task.I can see a dynamic programming solution to this problem.
Atri Sent from my iPad On 20-Mar-2013, at 21:33, Thom Brown <t...@linux.com> wrote: > On 19 March 2013 17:42, Thom Brown <t...@linux.com> wrote: >> On 14 February 2013 18:02, Josh Berkus <j...@agliodbs.com> wrote: >>> Folks, >>> >>> Once again, Google is holding Summer of Code. We need to assess whether >>> we want to participate this year. >>> >>> Questions: >>> >>> - Who wants to mentor for GSOC? >>> >>> - Who can admin for GSOC? Thom? >>> >>> - Please suggest project ideas for GSOC >>> >>> - Students seeing this -- please speak up if you have projects you plan >>> to submit. >> >> If anyone else has more projects ideas to suggest, please do share. >> Students, please feel free to review the PostgreSQL Todo list for >> inspiration: http://wiki.postgresql.org/wiki/Todo Of course ensure >> you don't choose anything too ambitious or trivial. > > Okay, here's a random idea (which could be infeasible and/or > undesirable). How about a way to internally schedule tasks using a > background worker process (introduced in 9.2) to wake on each tick and > run tasks? > > So: > > CREATE EXTENSION pg_scheduler; > -- > schedule_task(task_command, task_priority, task_start, repeat_interval); > > SELECT schedule_task('REINDEX my_table', 1, '2012-03-20 > 00:10:00'::timestamp, '1 week'::interval); > > SELECT list_tasks(); > > -[ RECORD 1 ]---+----------------------- > task_id | 1 > task_command | REINDEX my_table > task_priority | 1 > task_start | 2012-03-20 00:10:00-04 > repeat_interval | 7 days > owner | postgres > > SELECT delete_task(1); > > Tasks would be run in sequence if they share the same scheduled time > ordered by priority descending, beyond which it would be > non-deterministic. Or perhaps additional worker processes to fire > commands in parallel if necessary. > > Disclaimer: I haven't really thought this through. > > -- > Thom > > > -- > Sent via pgsql-advocacy mailing list (pgsql-advoc...@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-advocacy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
