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