Horton

Re: Slow count(*) again...

Jesper Krogh <jesper@krogh.cc>

View thread
From: Jesper Krogh <jesper@krogh.cc>
To: Scott Carey <scott@richrelevance.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mladen Gogala <mladen.gogala@vmsinfo.com>, "david@lang.hm" <david@lang.hm>, Craig Ringer <craig@postnewspapers.com.au>, Vitalii Tymchyshyn <tivv00@gmail.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2010-10-21T18:13:24Z
Lists: pgsql-hackers, pgsql-performance 
On 2010-10-21 06:47, Scott Carey wrote:
>  On a wimpy disk, I/O bound for sure.   But my disks go 1000MB/sec.
>  No query can go fast enough for them.  The best I've gotten is
>  800MB/sec, on a wide row (average 800 bytes).  Most tables go
>  300MB/sec or so.  And with 72GB of RAM, many scans are in-memory
>  anyway.

Is it cpu or io bound while doing it?

Can you scan it faster using time cat relation-oid.* > /dev/null

>  A single SSD with supercapacitor will go about 500MB/sec by itself
>  next spring.   I will easily be able to build a system with 2GB/sec
>  I/O for under $10k.

What filesystem are you using? Readahead?
Can you try to check the filesystemfragmentation of the table using filefrag?

-- 
Jesper