Robert Haas <robertmhaas@xxxxxxxxx> writes: > I wonder if it would be possible to have a very short critical section > where we grab the partition lock, acquire the heavyweight lock, and > release the partition lock; and then only as a second step record (in > the form of a PROCLOCK) the fact that we got it. [ confused... ] Exactly what do you suppose "acquire the lock" would be represented as, if not "create a PROCLOCK entry attached to it"? In any case, I think this is another example of not understanding where the costs really are. As far as I can tell, on modern MP systems much of the elapsed time in these operations comes from acquiring exclusive access to shared-memory cache lines. Reducing the number of changes you have to make within a small area of shared memory won't save much, once you've paid for the first one. Changing structures that aren't heavily contended (such as a proc's list of its own locks) doesn't cost much at all. One thing that might be interesting, but that I don't know how to attack in a reasonably machine-independent way, is to try to ensure that shared and local data structures don't accidentally overlap within cache lines. When they do, you pay for fighting the cache line away from another processor even when there's no real need. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
