pgsql: Improve LISTEN startup time when there are many unread notificat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Improve LISTEN startup time when there are many unread notificat
Date: 2015-10-01 03:33:03
Message-ID: E1ZhUcB-00064x-6O@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Improve LISTEN startup time when there are many unread notifications.

If some existing listener is far behind, incoming new listener sessions
would start from that session's read pointer and then need to advance over
many already-committed notification messages, which they have no interest
in. This was expensive in itself and also thrashed the pg_notify SLRU
buffers a lot more than necessary. We can improve matters considerably
in typical scenarios, without much added cost, by starting from the
furthest-ahead read pointer, not the furthest-behind one. We do have to
consider only sessions in our own database when doing this, which requires
an extra field in the data structure, but that's a pretty small cost.

Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced.

Matt Newell, slightly adjusted by me

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/07e4d03fb476587bd943b4ba7d51bf0bb559a631

Modified Files
--------------
src/backend/commands/async.c | 49 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 5 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2015-10-01 03:37:45 pgsql: Fix errors in commit a04bb65f70dafdf462e0478ad19e6de56df89bfc.
Previous Message Robert Haas 2015-09-30 23:29:30 pgsql: Add a Gather executor node.