From: Mark Kirkwood <markir@paradise.net.nz>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: Dave Cramer <pg@fastcrypt.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Joshua Marsh <icub3d@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Hardware/OS recommendations for large databases (
Date: Sat, 19 Nov 2005 12:46:54 +1300
Message-ID: <437E67EE.4070605@paradise.net.nz> (raw)
In-Reply-To: <BFA32FA6.14027%llonergan@greenplum.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: markir@paradise.net.nz, llonergan@greenplum.com, pg@fastcrypt.com, gsstark@mit.edu, icub3d@gmail.com
Subject: Re: Hardware/OS recommendations for large databases (
In-Reply-To: <437E67EE.4070605@paradise.net.nz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox