On Wed, May 30, 2012 at 9:10 PM, Sergey Koposov <koposov@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
