I wasn't involved in this work but I do know a bit about it. Sadly, the work on Postgres performance was cut down to under a page, complete with the amazing offhand mention of "rewriting PostgreSQL's lock manager". Here are a few more details... The benchmarks in this paper are all about stressing the kernel. The database is entirely in memory -- it's stored on tmpfs rather than on disk, and it fits within shared_buffers. The workload consists of index lookups and inserts on a single table. You can fill in all the caveats about what conclusions can and cannot be drawn from this workload. The big takeaway for -hackers, I think, is that lock manager performance is going to be an issue for large multicore systems, and the uncontended cases need to be lock-free. That includes cases where multiple threads are trying to acquire the same lock in compatible modes. Currently even acquiring a shared heavyweight lock requires taking out an exclusive LWLock on the partition, and acquiring shared LWLocks requires acquiring a spinlock. All of this gets more expensive on multicores, where even acquiring spinlocks can take longer than the work being done in the critical section. Their modifications to Postgres should be available in the code that was published last night. As I understand it, the approach is to implement LWLocks with atomic operations on a counter that contains both the exclusive and shared lock count. Heavyweight locks do something similar but with counters for each lock mode packed into a word. Note that their implementation of the lock manager omits some features for simplicity, like deadlock detection, 2PC, and probably any semblance of portability. (These are the sort of things we're allowed to do in the research world! :-) The other major bottleneck they ran into was a kernel one: reading from the heap file requires a couple lseek operations, and Linux acquires a mutex on the inode to do that. The proper place to fix this is certainly in the kernel but it may be possible to work around in Postgres. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
