On Wed, May 30, 2012 at 9:10 PM, Sergey Koposov <kopo...@ast.cam.ac.uk> wrote: > I understand the need of significant locking when there concurrent writes, > but not when there only reads. But I'm not a RDBMS expert, so that's maybe > that's misunderstanding on my side.
If we knew in advance that no writes would come along during the execution of a particular test case, then we could skip a lot of locking on the reads. But we don't, so we have to be prepared for the possibility of writes at any time, which means doing things taking share-locks on data while it's actively being read. Also, even in an entirely read-only workload, buffers can get evicted from the database buffer cache, so we have to lock to make sure a buffer doesn't get evicted while we're reading it. I'd really like to find out exactly where all those s_lock calls are coming from. Is there any way you can get oprofile to output a partial stack backtrace? If you have perf it's very easy, just 'perf record -g -a <command to launch your test case>' and then 'perf report -g'. -- 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
