Hiya! PgQ looks like cool technology, but it still violates the #1 thing I'm looking for, which is a postgres-only solution. I don't see any reason why I'd want an external daemon ticking the system over, and I'm hoping perhaps there's some way to coax Postgres itself into doing this asychronous job processing, akin to the dblink technique mentioned twice today, but not ugly.
NOTIFY/LISTEN again comes spiritually close, but is still restrained to only being a useful construct for database clients; there's no resident processes that can react to database events, and that's kind of a shame IMO. -rektide On Tue, Dec 11, 2012 at 12:58:21PM -0800, Sergey Konoplev wrote: > Hi, > > On Tue, Dec 11, 2012 at 11:29 AM, rektide <rekt...@voodoowarez.com> wrote: > > Does anyone have suggestions for decoupling work done on a server, for > > breaking up a task > > into multiple asychronous pieces? I believe I've described 1. a viable if > > ugly means of > > doing so, and 2. limitations in the primary asynchronous toolsuite of > > Postgres, and am > > looking for ways to make more progress. > > Use PgQ (http://wiki.postgresql.org/wiki/PGQ_Tutorial) for this > purpose. It is simple to implement solution and it will allow you to > preserve your queries between server restarts. > > -- > Sergey Konoplev > Database and Software Architect > http://www.linkedin.com/in/grayhemp > > Phones: > USA +1 415 867 9984 > Russia, Moscow +7 901 903 0499 > Russia, Krasnodar +7 988 888 1979 > > Skype: gray-hemp > Jabber: gray...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
