Avoid unnecessary pg_listening_channels queries on connection release

[kitogo]

There's no need to unlisten on all channels if there are no active listeners on the connection. Querying pg_listening_channels could be quite time consuming even when no listeners are added. For example, 20% of all time spent on DB operations goes to pg_listening_channels on our project.

[elprans]

This doesn't account for any potential listeners created with LISTEN instead of with the connection API.

[mikosowski]

Hi! Any news on this PR? I have similar issue: we don't add any listeners, but pg_listening_channels is queried every time when connection is reseted. It's quite time consuming. Is there any solution for this?

[kitogo]

Sorry, I kinda dropped the ball on this one.
Thanks a lot for the feedback @elprans , I didn't think about that use case. I can look into extending _ClientConfiguration to include a flag that can be used to disable listeners API on the connection. This of course would still allow creating listeners with LISTEN, but at least as a user you would explicitly disable subscribing/unsubscribing to Postgres notifications through asyncpg API and would have to deal with this manually if you decide to useLISTEN. Does this sound like a feasible solution?

[mikosowski]

For me this solution is completely OK ;) I'll be very happy if we push forward the work on this PR.

[elprans]

The majority of the overhead here comes from the use of the PL/pgSQL DO block, which is actually not necessary. IIRC, it was added to guard against some old/alternative Postgres implementation, but that case can be solved by tweaking capabilities instead. Dropping the conditional block around UNLISTEN removes over 50% of the acquire()/release() overhead:

diff --git a/asyncpg/connection.py b/asyncpg/connection.py
index e62928f..13b8283 100644
--- a/asyncpg/connection.py
+++ b/asyncpg/connection.py
@@ -1500,17 +1500,8 @@ class Connection(metaclass=ConnectionMeta):
             _reset_query.append('SELECT pg_advisory_unlock_all();')
         if caps.sql_close_all:
             _reset_query.append('CLOSE ALL;')
-        if caps.notifications and caps.plpgsql:
-            _reset_query.append('''
-                DO $$
-                BEGIN
-                    PERFORM * FROM pg_listening_channels() LIMIT 1;
-                    IF FOUND THEN
-                        UNLISTEN *;
-                    END IF;
-                END;
-                $$;
-            ''')
+        if caps.notifications:
+            _reset_query.append('UNLISTEN *;')
         if caps.sql_reset:
             _reset_query.append('RESET ALL;')

[kitogo]

Great, thanks for clarification on this @elprans ! Seems like conditional block around UNLISTEN was added in 2b104e0 to fix connection reset when running against instances in hot standby mode, since PostgreSQL versions older than 9.4 didn't support UNLISTEN in hot standby. This shouldn't be a problem in all supported PostgreSQL versions though. I will update this PR to only include changes you've suggested in the comment.