Re: Optimize LISTEN/NOTIFY

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Arseniy Mukhin" <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2025-10-15 21:10:47
Message-ID: def143ea-2425-489e-9699-713f9fccb27f@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-15 21:15:15 Re: Optimize LISTEN/NOTIFY
Previous Message Melanie Plageman 2025-10-15 21:00:30 Re: Eagerly evict bulkwrite strategy ring