Date: Sat, 19 Nov 2005 12:46:54 +1300
From: Mark Kirkwood <markir@paradise.net.nz>
Subject: Re: Hardware/OS recommendations for large databases (
In-reply-to: <BFA32FA6.14027%llonergan@greenplum.com>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: Dave Cramer <pg@fastcrypt.com>, Greg Stark <gsstark@mit.edu>,
	Joshua Marsh <icub3d@gmail.com>, pgsql-performance@postgresql.org
Message-id: <437E67EE.4070605@paradise.net.nz>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 8BIT
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106)
References: <BFA32FA6.14027%llonergan@greenplum.com>

Luke Lonergan wrote:

>     (mass snippage) 
>     time psql -c "select count(*) from ivp.bigtable1" dgtestdb
>     [llonergan@modena2 IVP]$ cat sysout3
>       count   
>     ----------
>      80000000
>     (1 row)
> 
> 
>     real    1m9.875s
>     user    0m0.000s
>     sys     0m0.004s
>     [llonergan@modena2 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