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: Ants Aasma <ants@cybertec.at>
Cc: Merlin Moncure <mmoncure@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Florian Pflug <fgp@phlo.org>, Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers@postgresql.org, Stephen Frost <sfrost@snowman.net>
Date: 2012-06-06T19:53: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 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/