Re: [HACKERS] INHERITS and planning

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Your suggested fix to the 2000+ inherited relation problem seemed like
> it would apply to an area that most people would never use, yet would
> have an effect on anybody using LockAcquire.

Just FYI, the proposed fix is already in, and I think it's a net win for
anyone. LockCountMyLocks was really an artifact of a lock API that's
been superseded by events --- namely the assumption that we want to take
locks in the names of particular transactions rather than in the names
of particular backends. I put that in around 7.1 or so, primarily to
support "session locks" for VACUUM, but designed it the way I did with
the idea that subtransactions would someday want it. In the event,
subtransactions didn't want it --- it was a lot cheaper to add the
backend-private LOCALLOCK tables and make all the subtransaction
bookkeeping happen internally to a backend. Now that we have LOCALLOCK
the obvious next step is to manage session locks entirely within
LOCALLOCK too, and reduce the shared-memory state to essentially one bit
per lock per backend: "I hold it" or "I don't hold it". When you know
there is only one proclock per backend, there's no need to search for
other ones and thus LockCountMyLocks goes away again.

regards, tom lane