Joe Conway wrote:
In isolation, test_run.sql should do essentially no syscalls at all once
it's past the initial ramp-up.  On a machine that's functioning per
expectations, multiple copies of test_run show a relatively low rate of
semop() calls --- a few per second, at most --- and maybe a delaying
select() here and there.


Here's results for 7.4 on a dual Athlon server running fedora core:


CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total   86.0%    0.0%   52.4%   0.0%     0.0%    0.0%   61.2%
           cpu00   37.6%    0.0%   29.7%   0.0%     0.0%    0.0%   32.6%
           cpu01   48.5%    0.0%   22.7%   0.0%     0.0%    0.0%   28.7%

procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs
1 0 120448 25764 48300 1094576 0 0 0 124 170 187
1 0 120448 25780 48300 1094576 0 0 0 0 152 89
2 0 120448 25744 48300 1094580 0 0 0 60 141 78290
2 0 120448 25752 48300 1094580 0 0 0 0 131 140326
2 0 120448 25756 48300 1094576 0 0 0 40 122 140100
2 0 120448 25764 48300 1094584 0 0 0 60 133 136595
2 0 120448 24284 48300 1094584 0 0 0 200 138 135151


The jump in cs corresponds to starting the query in the second session.

Joe


---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Reply via email to