Re: Workqueue performance - Mailing list pgsql-general

From Tom Lane
Subject Re: Workqueue performance
Date
Msg-id 5810.1273587207@sss.pgh.pa.us
Whole thread Raw
In response to Workqueue performance  (Jason Armstrong <ja@riverdrums.com>)
Responses Re: Workqueue performance  (Jason Armstrong <ja@riverdrums.com>)
List pgsql-general
Jason Armstrong <ja@riverdrums.com> 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 running (ie just insert
> into the log.file table, with the fileworkqueue.job table being filled
> up by the trigger), we see a rate of about 3 milliseconds per insert.
> When it is run with the workers removing data from the
> fileworkqueue.job table, this drops to below 50 Ms.

Not sure if this is the source of your issue, but have you checked how
many dead rows are in pg_listener?  Applications that are making heavy
use of NOTIFY/LISTEN tend to need *very* aggressive vacuuming of that
table in order to keep performance up.

(FWIW, 9.0 will have a rewritten notify mechanism that eliminates this
problem.  Doesn't help you today though.)

            regards, tom lane

pgsql-general by date:

Previous
From: Grzegorz Jaśkiewicz
Date:
Subject: 8.3.7, 'cache lookup failed' for a table
Next
From: Tom Lane
Date:
Subject: Re: can function arguments have the type tablename.columnname%TYPE?