Luke Lonergan wrote:
(mass snippage)
time psql -c "select count(*) from ivp.bigtable1" dgtestdb
[EMAIL PROTECTED] IVP]$ cat sysout3
count
----------
80000000
(1 row)
real 1m9.875s
user 0m0.000s
sys 0m0.004s
[EMAIL PROTECTED] IVP]$ !du
du -sk dgtestdb/base
17021260 dgtestdb/base
Summary:
<cough, cough> OK – you can get more I/O bandwidth out of the current
I/O path for sequential scan if you tune the filesystem for large
readahead. This is a cheap alternative to overhauling the executor to
use asynch I/O.
Still, there is a CPU limit here – this is not I/O bound, it is CPU
limited as evidenced by the sensitivity to readahead settings. If the
filesystem could do 1GB/s, you wouldn’t go any faster than 244MB/s.
Luke,
Interesting - but possibly only representative for a workload consisting
entirely of one executor doing "SELECT ... FROM my_single_table".
If you alter this to involve more complex joins (e.g 4. way star) and
(maybe add a small number of concurrent executors too) - is it still the
case?
Cheers
Mark
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
