From: | Gianni Ciolli <gianni(dot)ciolli(at)2ndquadrant(dot)it> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Proposed fix for NOTIFY performance degradation |
Date: | 2011-04-23 13:57:32 |
Message-ID: | 20110423135732.GA16097@albo.gi.lan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
while measuring NOTIFY execution time, I noticed a significant
performance drop.
Please find a patch attached, together with some tests; more details
are shown below.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it
---8<------8<------8<------8<------8<------8<------8<------8<------8<---
h1. The problem
We record pending notifications in a transaction-based list.
Notifications are recorded in the same order as they are issued.
Because of PostgreSQL's asynchronous notification semantics, we don't
need to record two identical notifications; we record a notification
only if there are no duplicates.
This is implemented by scanning the list and checking for duplicates.
The list is scanned backwards because the last element is easily
accessible, which is a sensible optimisation in the case of many
notifications which are identical to the previous one (scenario A).
However, scanning the list is quite expensive in the case of many
notifications which are not identical to the previous one (scenario B,
see Test 1 below when m > 1).
h1. Proposed solution
To check only the last element in that list, which is efficient in
both scenarios (see Test 2 below).
h1. Tests
"PostgreSQL HEAD" has been fetched as after commit #a0e8df52 (Wed Apr
20 22:49:37 2011 -0400).
Test 1 has been executed against PostgreSQL HEAD.
Test 2 has been executed against patched version of PostgreSQL HEAD.
In the tables below:
* "n" denotes the number of notifications issued in a single
transaction;
* "m" denotes the number of distinct channels used for these
notifications;
* "iter" is the number of times each transaction has been repeated (to
reduce the importance of occasional spikes);
* "avg_usec" denotes the average time in microseconds required by each
NOTIFY statement.
h2. Test 1 - PostgreSQL HEAD
n | m | iter | avg_usec
-------+-------+------+----------
10 | 1 | 10 | 43.730
100 | 1 | 10 | 37.630
1000 | 1 | 10 | 42.990
10000 | 1 | 10 | 36.225
10 | 10 | 10 | 43.960
100 | 100 | 10 | 46.537
1000 | 1000 | 10 | 126.115
10000 | 10000 | 10 | 906.501
h2. Test 2 - patched PostgreSQL
n | m | iter | avg_usec
-------+-------+------+----------
10 | 1 | 10 | 43.810
100 | 1 | 10 | 38.256
1000 | 1 | 10 | 36.950
10000 | 1 | 10 | 36.638
10 | 10 | 10 | 44.830
100 | 100 | 10 | 38.684
1000 | 1000 | 10 | 38.924
10000 | 10000 | 10 | 38.032
Attachment | Content-Type | Size |
---|---|---|
notify-optimisation.diff | text/x-diff | 1.5 KB |
test.sql | application/x-sql | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Woodcraft | 2011-04-23 13:58:57 | Re: fsync reliability |
Previous Message | Kevin Grittner | 2011-04-23 13:54:31 | Re: SSI non-serializalbe UPDATE performance (was: getting to beta) |