Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Date: 2017-05-11 21:28:12
Message-ID: 9141.1494538092@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote:
>> (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.

My results (posted nearby) lead me to suspect that the improvement
Peter sees from 9.1 to 9.2 has little to do with fastpath locking
and a lot to do with some improvement or other in subtransaction
lock management.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2017-05-11 21:28:39 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Tom Lane 2017-05-11 21:21:18 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-05-11 21:28:39 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Tom Lane 2017-05-11 21:21:18 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression