Hi, On 2020-02-19 11:12:18 +0530, Amit Kapila wrote: > I think till we know the real need for changing group locking, going > in the direction of what Tom suggested to use an array of LWLocks [1] > to address the problems in hand is a good idea.
-many I think that building yet another locking subsystem is the entirely wrong idea - especially when there's imo no convincing architectural reasons to do so. > It is not very clear to me that are we thinking to give up on Tom's > idea [1] and change group locking even though it is not clear or at > least nobody has proposed an idea/patch which requires that? Or are > we thinking that we can do what Tom suggested for relation extension > lock and also plan to change group locking for future parallel > operations that might require it? What I'm advocating is that extension locks should continue to go through lock.c. And yes, that requires some changes to group locking, but I still don't see why they'd be complicated. And if there's concerns about the cost of lock.c, I outlined a pretty long list of improvements that'll help everyone, and I showed that the locking itself isn't actually a large fraction of the scalability issues that extension has. Regards, Andres
