Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
| От | Andres Freund |
|---|---|
| Тема | Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
| Дата | |
| Msg-id | 20170511204012.pf2k4jmauyebfxkw@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
|
| Список | pgsql-hackers |
Hi, On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote: > On 5/10/17 12:24, Andres Freund wrote: > > Upthread I theorized whether > > that's actually still meaningful given fastpath locking and such, but I > > guess we'll have to evaluate that. > > I did some testing. That's with the open_share_lock stuff ripped out entirely, replaced by a plain lock acquisition within the current subxact? > (These were within each other's variance over several runs.) > > 9.2 unpatched > Time: 64868.305 ms > > 9.2 patched > Time: 60585.317 ms > > (So without contention fast-path locking beats the extra dance that > open_share_lock() does.) That's kind of surprising, I really wouldn't have thought it'd be faster without. I guess it's the overhead of sigsetjmp(). Cool. - Andres
В списке pgsql-hackers по дате отправления: