Skip site navigation (1) Skip section navigation (2)

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

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Date: 2012-05-30 21:07:43
Message-ID: D6D1FDEF-E230-4ACB-BE63-F090096C459E@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On May30, 2012, at 22:07 , Sergey Koposov wrote:
> If I restart the db the timings do not change significantly. There is always some variation which I don't really understand, e.g. the parallel runs sometimes
> take 18s, or 25 seconds, or 30 seconds per thread. So there is something else affecting
> the runs -- I don't know, maybe that's related to which thread starts first,
> or what is the starting point of the seq scan... (there is no other activity on the machine btw).

I wonder if the huge variance could be caused by non-uniform synchronization costs across different cores. That's not all that unlikely, because at least some cache levels (L2 and/or L3, I think) are usually shared between all cores on a single die. Thus, a cache bouncing line between cores on the same die might very well be faster then it bouncing between cores on different dies.

On linux, you can use the taskset command to explicitly assign processes to cores. The easiest way to check if that makes a difference is to assign one core for each connection to the postmaster before launching your test. Assuming that cpu assignment are inherited to child processes, that should then spread your backends out over exactly the cores you specify.

best regards,
Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Florian PflugDate: 2012-05-30 21:38:57
Subject: Re: Fake async rep target
Previous:From: Sergey KoposovDate: 2012-05-30 20:35:44
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group