Luke Lonergan wrote:

(mass snippage) time psql -c "select count(*) from ivp.bigtable1" dgtestdb
    [EMAIL PROTECTED] IVP]$ cat sysout3
count ----------
    (1 row)

    real    1m9.875s
    user    0m0.000s
    sys     0m0.004s
    du -sk dgtestdb/base
    17021260        dgtestdb/base


<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.


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?



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to