Horton

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

Sergey Koposov <koposov@ast.cam.ac.uk>

View thread
From: Sergey Koposov <koposov@ast.cam.ac.uk>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-05-24T17:42:33Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve bulk-insert performance by keeping the current target buffer pinned

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