> Maybe it is just the PK *build* that slows it down, but I just tried some
> small scale experiments on my MacBook Pro laptop (which has the same disk
> performance as your server) and I get only a 10-15% slowdown from having a
> PK on an integer column. The 10-15% slowdown was on 8.1.5 MPP, so it used
> both CPUs to build the index and load at about 15 MB/s.
...snip...
> What is your schema for the table?
A single IP4 PK and 21 VARCHARs. It takes about 340 seconds to load a
1.9GB file with the PK index, and about 230 seconds without it (ALTER
TABLE mytable DROP CONSTRAINT mytable_pkey), which is a pretty
significant (~30%) savings. If I read the vmstat output correctly
(i.e. the cpu us column), I'm still at 12% and thus still cpu-bound,
except for when the checkpoint occurs, i.e (everything is chugging
along similar to the first line, then stuff gets wonky):
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 279028 4620040 717940 9697664 0 0 0 19735 1242 7534 13 4 82 1
1 2 279028 4476120 718120 9776840 0 0 0 2225483 1354 5269 13 6 71 11
0 3 279028 4412928 718320 9866672 0 0 2 19746 1324 3978 10 2 69 18
1 1 279028 4334112 718528 9971456 0 0 0 20615 1311 5912 10 3 69 18
0 1 279028 4279904 718608 9995244 0 0 0 134946 1205 674 1 3 85 11
0 2 279028 4307344 718616 9995304 0 0 0 54 1132 247 0 1 77 22
1 0 279028 7411104 718768 6933860 0 0 0 9942 1148 3618 11 6 80 3
1 0 279028 7329312 718964 7015536 0 0 1 19766 1232 5108 13 2 84 1
Also, as a semi-side note, I only have a single checkpoint without the
index, while I have 2 with the index.