Re: [PATCH] Improve performance of NOTIFY over many databases (issueblocking on AccessExclusiveLock on object 0 of class 1262 of database 0)
От | Martijn van Oosterhout |
---|---|
Тема | Re: [PATCH] Improve performance of NOTIFY over many databases (issueblocking on AccessExclusiveLock on object 0 of class 1262 of database 0) |
Дата | |
Msg-id | CADWG95v-ki2UKg+9TmRzLrxhCb_Pk5WgQ2djGvPkodLbAw38DQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Improve performance of NOTIFY over many databases (issue blocking on AccessExclusiveLock on object 0 of class 1262 of database 0) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Improve performance of NOTIFY over many databases (issueblocking on AccessExclusiveLock on object 0 of class 1262 of database 0)
|
Список | pgsql-hackers |
On Tue, 23 Jul 2019 at 23:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Martijn van Oosterhout <kleptog@gmail.com> writes: > > I mean tracking the listening backends specifically, so you can > > replace the loops: > > for (i=0; i < MaxBackends; i++) > > with > > for (i=QUEUE_FIRST_LISTENING_BACKEND; i; i = QUEUE_NEXT_LISTENING_BACKEND(i)) > > Ah ... but surely you would not put such info in AsyncQueueEntry, > where there'd be a separate copy for each message. I think you > meant to add the info to AsyncQueueControl. Umm, yeah. Got that mixed up. > It might be better to redefine the backends[] array as being mostly > contiguous (ie, a new backend takes the first free slot not the one > indexed by its own BackendId), at the price of needing to store > BackendId in each slot explicitly instead of assuming it's equal to > the array index. I suspect the existing data structure is putting too > much of a premium on making sizeof(QueueBackendStatus) a power of 2. This would require adding a "MyListenerId" to each backend which I'm not sure helps the readability. And there's a chance of mixing the id up. The power-of-2-ness is I think indeed overrated. I'll give it a shot a see how it looks. Have a nice day, -- Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/
В списке pgsql-hackers по дате отправления: