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

On Thu, 24 May 2012, Merlin Moncure wrote:

> Are you sure? I looked at all the ReleasePredicateLocks calls and
> they appear to be guarded by:
>
> /* Nothing to do if this is not a serializable transaction */
> if (MySerializableXact == InvalidSerializableXact)
> return false;
> What's the default isolation mode set to?

Sorry, it was indeed my mistake. I was pointing opreport to the
binary which was recompiled, while the old version was still running , so
I guess oprofile was picking up wrong function names

Here is the correct oprofile: when multiple queries are running :
samples % symbol name
-------------------------------------------------------------------------------
952457 13.8715 LWLockAcquire
952457 100.000 LWLockAcquire [self]
-------------------------------------------------------------------------------
779077 11.3464 PinBuffer
779077 100.000 PinBuffer [self]
-------------------------------------------------------------------------------
759898 11.0671 s_lock
759898 100.000 s_lock [self]
-------------------------------------------------------------------------------
689753 6.7178 slot_deform_tuple
689753 100.000 slot_deform_tuple [self]
-------------------------------------------------------------------------------
526002 5.1230 UnpinBuffer
526002 100.000 UnpinBuffer [self]

When only one is running:
samples % symbol name
-------------------------------------------------------------------------------
163268 14.0343 slot_deform_tuple
163268 100.000 slot_deform_tuple [self]
-------------------------------------------------------------------------------
126018 10.8324 _bt_compare
126018 100.000 _bt_compare [self]
-------------------------------------------------------------------------------
113975 9.7972 ExecProject
113975 100.000 ExecProject [self]
-------------------------------------------------------------------------------
49760 4.2773 FunctionCall2Coll
49760 100.000 FunctionCall2Coll [self]
-------------------------------------------------------------------------------
49164 4.2261 LWLockAcquire
49164 100.000 LWLockAcquire [self]
-------------------------------------------------------------------------------
43526 3.7414 hash_search_with_hash_value
43526 100.000 hash_search_with_hash_value [self]

############

I guess there is nothing catastrophically wrong with that, but still I'm
very suprised that you get severe locking problems (factor of two
slow-down) when running parallel read-only transactions.

Sergey

*****************************************************
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK