On Mon, Jun 6, 2011 at 2:54 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Ah, I remember I saw that vxid lock pop up quite high in an oprofile profile > recently. I think it was the case of executing a lot of very simple prepared > queries. So it would be nice to address that, even from a single CPU point > of view.
It doesn't seem too hard to do, although I have to think about the details. Even though the VXID locks involved are Exclusive locks, they are actually very much like the "weak" locks that the current patch accelerates, because the Exclusive lock is taken only by the VXID owner, and it can therefore be safely assumed that the initial lock acquisition won't block anything. Therefore, it's really unnecessary to touch the primary lock table at transaction start (and to only touch it at the end if someone's waiting). However, there's a fly in the ointment: when someone tries to ShareLock a VXID, we need to determine whether that VXID is still around and, if so, make an Exclusive lock entry for it in the primary lock table. And, unlike what I'm doing for strong relation locks, it's probably NOT acceptable for that to acquire and release every per-backend LWLock, because every place that waits for VXID locks waits for a list of locks in sequence, so we could end up with O(n^2) behavior. Now, in theory that's not a huge problem: the VXID includes the backend ID, so we ought to be able to figure out which single per-backend LWLock is of interest and just acquire/release that one. Unfortunately, it appears that there's no easy way to go from a backend ID to a PGPROC. The backend IDs are offsets into the "ProcState" array, so they give us a pointer to the backend's sinval state, not its PGPROC. And while the PGPROC has a pointer to the sinval info, there's no pointer in the opposite direction. Even if there were, we'd probably need to hold SInvalWriteLock in shared mode to follow it. That might not be the end of the world, since VXID locks are fairly infrequently used, but it's certainly a little grotty. I do rather wonder if we should be trying to reduce the number of separate places where we list the running processes. We have arrays of PGPROC structures, and then we have one set of pointers to PGPROCs in the ProcArray, and then we have the ProcState structures for sinval. I wonder if there's some way to rearrange all this to simplify the bookkeeping. BTW, how do you identify from oprofile that *vxid* locks were the problem? I didn't think it could produce that level of detail. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
