Re: Poor performance on seq scan

>>  tin tout  KB/t tps  MB/s   KB/t   tps  MB/s  us ni sy in id
>>    1   14 128.00   1  0.10  128.00   1  0.10   5  0 94  1  0
>>    0   12 123.98 104 12.56  123.74 104 12.56   8  0 90  2  0
>>    0   12 125.66 128 15.75  125.26 128 15.68  10  0 85  6  0
>>    0   12 124.66 129 15.67  124.39 129 15.64  12  0 85  3  0
>>    0   12 117.13 121 13.87  117.95 121 13.96  12  0 84  5  0
>>    0   12 104.84 118 12.05  105.84 118 12.19  10  0 87  2  0
>
> Why is that showing 85+ percent *system* CPU time??  I could believe a
> lot of idle CPU if the query is I/O bound, or a lot of user time if PG
> was being a hog about doing the ~~ comparisons (not too unlikely BTW).
> But if the kernel is eating all the CPU, there's something very wrong,
> and I don't think it's Postgres' fault.

There IS a bug for SATA disk drives in some versions of the Linux kernel.  On a lark I ran some of the I/O tests in
thisthread, and much to my surprise discovered my write speed was 6 MB/sec ... ouch!  On an identical machine,
differentkernel, the write speed was 54 MB/sec. 

A couple of hours of research turned up this:

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363

The fix for me was to edit /boot/grub/grub.conf, like this:

   kernel /vmlinuz-2.6.12-1.1381_FC3 ro root=LABEL=/ rhgb quiet \
       ramdisk_size=12000000 ide0=noprobe ide1=noprobe

Notice the "ideX=noprobe".  Instant fix -- after reboot the disk write speed jumped to what I expected.

Craig