Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id def143ea-2425-489e-9699-713f9fccb27f@app.fastmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimize LISTEN/NOTIFY
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Eagerly evict bulkwrite strategy ring
Next
From: Tom Lane
Date:
Subject: Re: Optimize LISTEN/NOTIFY