Heikki Linnakangas napsal(a):
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is extended by even one block. I admit I've not
studied the data structure in any detail yet, but surely most such calls
end up being a no-op? Seems like some attention to making a fast path
for that case would be helpful.
Yes, most of those calls end up being no-op. Which is exactly why I
would be surprised if those made any difference. It does call
smgrnblocks(), though, which isn't completely free...
It is not a problem. It is really strange. I'm using DTrace to count number of
calls and number of calls is really small (I monitor only one backend). I have
removed WAL logging and it does not help too.
Zdenek, can you say off the top of your head whether the test was I/O
bound or CPU bound? What was the CPU utilization % during the test?
CPU is not problem it is mostly in idle time.
-bash-3.00# iostat 5
tty sd1 ssd0 ssd1 nfs1 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
0 1 0 0 1 9 1 92 0 0 0 0 0 0 0 0 0 100
0 47 0 0 0 894 111 7 0 0 0 0 0 0 2 1 0 97
0 16 0 0 0 949 118 6 0 0 0 0 0 0 2 2 0 97
0 16 0 0 0 965 120 6 0 0 0 0 0 0 2 1 0 97
0 16 0 0 0 981 122 7 0 0 0 0 0 0 2 2 0 96
0 16 0 0 0 944 118 6 0 0 0 0 0 0 2 1 0 97
0 16 0 0 0 1202 149 7 0 0 0 0 0 0 3 2 0 95
0 16 0 0 0 1261 157 9 0 0 0 0 0 0 3 2 0 95
0 16 0 0 0 1357 168 14 0 0 0 0 0 0 3 2 0 95
0 16 0 0 0 1631 201 33 0 0 0 0 0 0 2 2 0 96
0 16 0 0 0 1973 246 48 0 0 0 0 0 0 2 2 0 96
0 16 0 0 0 2008 251 50 0 0 0 0 0 0 2 2 0 97
0 16 0 0 0 1956 241 45 0 0 0 0 0 0 2 2 0 97
0 16 0 0 0 2003 250 49 0 0 0 0 0 0 2 2 0 97
-bash-3.00# vmstat 1
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s1 sd sd -- in sy cs us sy id
0 0 0 28091000 31640552 3 4 0 0 0 0 0 0 1 0 0 359 72 206 0 0 100
0 0 0 27363144 27614576 3 28 0 16 16 0 0 0 60 0 0 1216 1134 1072 1 1 99
0 0 0 27363144 27614568 8 0 0 16 16 0 0 0 52 0 0 1099 1029 964 0 1 98
0 0 0 27363144 27614560 9 0 0 8 8 0 0 0 53 0 0 1143 896 1009 1 1 98
0 0 0 27363144 27614544 1 241 0 16 16 0 0 0 46 0 0 1042 1105 895 0 1 98
0 0 0 27363144 27614544 0 0 0 16 16 0 0 0 50 0 0 1078 860 924 0 0 99
0 0 0 27363144 27614552 10 0 0 16 16 0 0 0 56 0 0 1177 914 1033 1 1 98
0 0 0 27363144 27614536 0 0 0 8 8 0 0 0 25 0 0 726 554 603 0 0 99
0 0 0 27363144 27614528 1 0 0 16 16 0 0 0 65 0 0 1206 1159 1081 1 1 98
0 0 0 27363144 27614512 13 0 0 16 16 0 0 0 63 0 0 1256 1088 1094 1 1 99
0 0 0 27363144 27614512 0 0 0 8 8 0 0 0 37 0 0 920 797 779 0 1 99
0 0 0 27363144 27614504 6 0 0 16 16 0 0 0 58 0 0 1218 1074 1078 1 0 99
0 0 0 27363144 27614488 85 91 0 16 16 0 0 0 45 0 0 973 1344 833 1 1 99
0 0 0 27363144 27614488 2 0 0 16 16 0 0 0 57 0 0 1164 1023 1036 1 1 99
0 0 0 27363144 27614472 4 0 0 8 8 0 0 0 47 0 0 1133 937 957 0 1 99
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
