On Mon, Nov 23, 2015 at 12:54 PM, John R Pierce <pierce@xxxxxxxxxxxx> wrote: > On 11/23/2015 2:41 AM, Chris Withers wrote: >> >> >> If it's totally wrong, how should I be looking to approach the problem? > > depending on where these queue entries are coming from, I'd considering > using a message queueing system like AMS, MQseries, etc, rather than trying > to use a relational database table as a queue. your external data source(s) > would write messages to this queue, and you'd have 'subscriber' processes > that listen to the queue and process the messages, inserting persistent data > into the database as needed. I just don't agree with this generalization. Keeping the state of the queue in the database has a lot of advantages and is a lot easier to deal with from a programming perspective especially if SQL is your core competency. Being able to produce and consume in SQL based on other relational datasources is...elegant. Specialized queue systems are a very heavy dependency and adding a new server to your platform to mange queues is not something to take lightly. This advice also applies to scheduling systems like quartz, specialized search like solr and elastisearch, and distributed data platforms like hadoop. I've used all of these things and have tended to wish I had just used the database instead in just about every case. Also, check out pgq (https://wiki.postgresql.org/wiki/PGQ_Tutorial). Personally, I tend to roll my own queues. It's not difficult. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
