From: | Gavin Mu <gavin(dot)mu(at)gmail(dot)com> |
---|---|
To: | Yeb Havinga <yhavinga(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Can LISTEN/NOTIFY deal with more than 100 every second? |
Date: | 2010-02-02 12:05:47 |
Message-ID: | 708189661002020405m23eac89dh2927bda5a7655ede@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
with your reminder I had a look at the code of the LISTEN/NOTIFY
implementation, NOTIFY <name> will send SIGUSR2 signal to the backend
if it's not for itself. I guess frequent singal handling can't be
handled on time.
2010/2/1 Yeb Havinga <yhavinga(at)gmail(dot)com>:
> Gavin Mu wrote:
>>
>> CREATE OR REPLACE RULE send_notify AS ON INSERT TO log DO ALSO NOTIFY
>> logevent;
>>
>
> ..
>>
>> when I use 3 similar programs to feed data, which means about 75
>> events every second, I found that Postgres didn't send NOTIFY
>> opportunely, since the client do SELECT query every several hundreds
>> seconds, which is too long to be acceptable.
>>
>
> Hello Gavin,
>
> The following might help from the notify docs:
>
> "NOTIFY behaves like Unix signals in one important respect: if the same
> notification name is signaled multiple times in quick succession, recipients
> might get only one notification event for several executions of NOTIFY."
>
> So if your notify for instance could also add a unique number to the
> notification name, then it will probably work as expected.
>
> Regards,
> Yeb Havinga
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Vincenzo Romano | 2010-02-02 12:26:34 | Partitioning: indexes, tables and FKs |
Previous Message | Clemens Schwaighofer | 2010-02-02 11:17:20 | Problem with partition tables and schemas |