Re: NOTIFY/LISTEN on server, asynchronous processing

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 <rektide(at)voodoowarez(dot)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(dot)ru(at)gmail(dot)com