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

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
allthat unlikely, because at least some cache levels (L2 and/or L3, I think) are usually shared between all cores on a
singledie. Thus, a cache bouncing line between cores on the same die might very well be faster then it bouncing between
coreson different dies. 

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

best regards,
Florian Pflug