Andres Freund <and...@anarazel.de> writes:
> On 2017-05-11 17:21:18 -0400, Tom Lane wrote:
>> I doubt my machine is 6X faster than yours,
>> so this indicates that the subtransaction overhead is pretty real.
> Isn't that pretty much the point? The whole open_share_lock()
> optimization looks like it really only can make a difference with
> subtransactions?
Uh, no; I'm pretty sure that that code is older than subtransactions.
The point of it is to avoid taking and releasing a lock over and over
within a single transaction.
>> Hm. I don't think that's a sufficient code change, because if you do it
>> like that then the lock remains held after nextval() returns.
> Hm? That's not new, is it? We previously did a LockRelationOid(seq->relid)
> and
> then relation_open(seq->relid, NoLock)?
Right, but the existing code is *designed* to hold the lock till end of
top-level transaction, regardless of what happens in any subtransaction.
My understanding of your complaint is that you do not think that's OK
for any lock stronger than AccessShareLock.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
