On Tue, Dec 11, 2012 at 1:48 PM, rektide <rektide@voodoowarez.com> wrote:
> 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
What is wrong with external solutions for you?
> 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.
Also do not forget that if nobody LISTENs you will loose such events.
>
> -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@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.ru@gmail.com
--
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.ru@gmail.com
