Jason Armstrong writes:
> 1. NOTIFY/LISTEN was causing performance to degrade badly over time. I
> have reworked my code to poll the database instead.
FWIW, you need to ensure pg_listener gets vacuumed pretty aggressively
in order to prevent degradation in a high-traffic NOTIFY application.
PG 9
Thank-you for the tips about this issue.
I found two things:
1. NOTIFY/LISTEN was causing performance to degrade badly over time. I
have reworked my code to poll the database instead.
2. There was a further function trigger that I didn't include in the
description. I wanted to keep a status of t
Jason Armstrong writes:
> My worker processes then 'LISTEN' for the appropriate NOTIFY, select
> the rows from the fileworkqueue.job table according to the
> 'filetype_id', and transfer them. After processing, it deletes the row
> from the workqueue.
> When we are processing without the workers r
On 5/11/2010 3:28 AM, Jason Armstrong wrote:
I have a performance question with a database workqueue I am working on.
I have two tables, the first containing information about files, and
the second is a workqueue table with 'jobs', intended for a worker
process to transfer the files to another
I have a performance question with a database workqueue I am working on.
I have two tables, the first containing information about files, and
the second is a workqueue table with 'jobs', intended for a worker
process to transfer the files to another machine:
> create table log.file (id uuid, cre
