Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

On Wed, May 30, 2012 at 9:10 PM, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)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