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
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 |