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 по дате отправления: