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
