Re: Optimize LISTEN/NOTIFY
| От | Joel Jacobson | 
|---|---|
| Тема | Re: Optimize LISTEN/NOTIFY | 
| Дата | |
| Msg-id | def143ea-2425-489e-9699-713f9fccb27f@app.fastmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Optimize LISTEN/NOTIFY (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: Optimize LISTEN/NOTIFY
            		
            		 | 
		
| Список | 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 по дате отправления: