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: pgsql-hackers@postgresql.org
Cc: Robert Haas <robertmhaas@gmail.com>, Merlin Moncure <mmoncure@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Stephen Frost <sfrost@snowman.net>, pgsql-hackers@postgresql.org
Date: 2012-05-27T18:45:19Z
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

Hi,

I did another test using the same data and the same code, which I've 
provided before and the performance of the single thread seems to be 
degrading quadratically with the number of threads.

Here are the results:
Nthreads Time_to_execute_one_thread
1 8.1
2 7.8
3 8.1
4 9.0
5 10.2
6 11.4
7 13.3
8 16.1
9 19.0
10 21.4
11 23.8
12 27.3
13 30.2
14 32.0
15 34.1
16 37.5

Regards,
 	Sergey



On Sat, 26 May 2012, Stephen Frost wrote:

> * Sergey Koposov (koposov@ast.cam.ac.uk) wrote:
>> Turning off synch seq scans doesn't help either. 18 sec
>> multithreaded run vs 7 sec single threaded.
>
> Alright, can you just time 'cat' when they're started a few seconds or
> whatever apart from each other?  I can't imagine it being affected in
> the same way as these, but seems like it wouldn't hurt to check.
>
> 	Thanks,
>
> 		Stephen
>

*****************************************************
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/