Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile - Mailing list pgsql-hackers

From Sergey Koposov
Subject Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date
Msg-id alpine.LRH.2.02.1206062017350.5707@calx046.ast.cam.ac.uk
Whole thread Raw
In response to Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Ants Aasma <ants@cybertec.at>)
Responses Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On Wed, 6 Jun 2012, Ants Aasma wrote:

> On Wed, Jun 6, 2012 at 2:27 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
>> I've quickly tested your lockfree-getbuffer.patch patch with the test case
>> you provided and I barely see any improvement (2% at max)
>> https://docs.google.com/open?id=0B7koR68V2nM1QVBxWGpZdW4wd0U
>> tested with 24 core (48 ht cores, Xeon E7- 4807).
>> Although the tps vs number of threads looks weird....
>
> Was this the range scan on the test table? (sorry about the error in
> the query, the x should really be id) In that case the results look
> really suspicious.

Yes, my fault partially, because without much thought I've put "value" 
instead of "x" in the script. Now after replacing it by "id" the tps are 
much smaller.

Here is the tps vs nthreads I did test up to 10 threads on my 24 cpu 
system (I disabled HT though):
https://docs.google.com/open?id=0B7koR68V2nM1Nk9OcWNJOTRrYVE

Your patch clearly improve the situation (the peak tps is ~ 10% higher), 
but the general picture is the same: flattening of tps vs nthreads.

Cheers,    S

*****************************************************
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoiding adjacent checkpoint records
Next
From: Alvaro Herrera
Date:
Subject: Re: \conninfo and SSL