Of course this could be done with pgAgent or it could be done with cron, but since it should be elegant, this calls for a background worker process.
For illustration purposes, I wrote a sample implementation called worker_ltt based on the worker_spi sample code. Sloppy - even the orginal comments are still in there.
Adding worker_ltt to shared_preload_libraries and
worker_ltt.naptime = 60
worker_ltt.database = 'yourdb'
worker_ltt.user = 'youruser'
worker_ltt.function = 'move_longtail'
to postgresql.conf starts executing move_longtail() every 60 seconds in yourdb as youruser. If the user is omitted, it runs with superuser rights!
Since move_longtail() basically can do anything, restricting the user is a good idea.
For more security, the SQL statements could be moved entirely into the background worker, but then the approach loses much of its flexibility... But this is a concept anyway, there is always room for improvement.
But it really works.
In part III I'll try to give a raw estimate how big the performance penalty is when the partitioned table switches from fast to slow storage during a query. And there is another important problem to be solved...