Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture
От | Andres Freund |
---|---|
Тема | Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture |
Дата | |
Msg-id | 7fnnh5pr65hqfhw3rpoijhogu26c3pn6shxr2wdsqmh2vzvuyq@eom6cddxfcrd обсуждение исходный текст |
Ответ на | Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture (Álvaro Herrera <alvherre@kurilemu.de>) |
Ответы |
Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture
|
Список | pgsql-hackers |
Hi, On 2025-08-14 11:29:08 +0200, Álvaro Herrera wrote: > On 2025-May-01, Tom Lane wrote: > > > One other thing that comes to mind is that pg_stat_statements > > has stretched the intention of "short straight-line code segment" > > to the point of unrecognizability. Maybe it needs to stop using > > spinlocks to protect pgssEntry updates. But I'm not sure if that > > would move the needle on whether ISB is a good idea or not. > > Yeah, it looks like pgss_store() is being too generous on the amount of > code run with that spinlock held. Indeed. To the point that these days pgss is basically unusable for workloads with many short queries. > However, changing that spinlock to an lwlock doesn't look easy, because of > the way each pgss entry is created as a dynahash entry, and then deallocated > from there. With spinlocks we can just reinit the spinlock each time, but > that doesn't work with lwlocks. We have no easy way to associate then > disassociate each entry from a specific lwlock. I'm not following? The lwlock can just be inside the struct, just like the spinlock is? "Association" is just LWLockInitialize() and deassociation is not needed. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: