Horton

Re: Optimize LISTEN/NOTIFY

Joel Jacobson <joel@compiler.org>

View thread
From: "Joel Jacobson" <joel@compiler.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Arseniy Mukhin" <arseniy.mukhin.dev@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-15T21:10:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize LISTEN/NOTIFY via shared channel map and direct advancement.

  2. Fix incorrect logic for caching ResultRelInfos for triggers

On Wed, Oct 15, 2025, at 16:16, Tom Lane wrote:
> I think we can perhaps salvage the idea if we invent a separate
> "advisory" queue position field, which tells its backend "hey,
> you could skip as far as here if you want", but is not used for
> purposes of SLRU truncation. 

I want to experiment with this idea too.

I assume the separate "advisory" queue position field
would actually need to be two struct fields, since a queue position
consists of a page and an offset, right?

   typedef struct QueuePosition
   {
     int64		page;			/* SLRU page number */
     int			offset;			/* byte offset within page */
+    int64		advisoryPage;	/* suggested skip-ahead page */
+    int			advisoryOffset;	/* suggested skip-ahead offset */
   } QueuePosition;

Or would we want rather want a single "advisory" field that would also
be of type QueuePosition?

/Joel