From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: random observations while testing with a 1,8B row |
Date: | 2006-03-11 08:29:16 |
Message-ID: | C037CA5C.1F01E%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stefan,
On 3/11/06 12:21 AM, "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc> wrote:
>> So - you're getting 20MB/s on loading from a potential of 200MB/s?
>
> no - I can write 110MB/s on thw WAL LUN and 110MB/s on the other LUN
> concurrently.
The numbers you published earlier show you are getting a maximum of 20MB/s
on data loading. It's CPU limited by Postgres COPY.
> Beside that, sequential-io as you are propagating everywhere is NOT the
> holy grail or the sole solution to a fast database.
> While the SAN above really is not a screamer for that kind of
> application it is actually a very good performer(compared with some of
> the DASD based boxes) under heavy random-io and concurrent load.
> This has a direct measurable influence on the overall speed of our
> production applications which are mostly OLTP ;-)
The same DASD can be configured with RAID10 and will far surpass the
external FC SAN configuration you describe at the same price.
The DASD story is not all about sequential I/O. The main limitation is the
number of devices you can make available using DASD, and that's a Postgres
limitation that we solve.
For OLTP apps, you may be fast enough with the limited bandwidth of your FC
SAN, but it would still be faster with hundreds of channels and disks.
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-03-11 08:49:36 | Re: There is a problem with the download site? |
Previous Message | Stefan Kaltenbrunner | 2006-03-11 08:21:15 | Re: random observations while testing with a 1,8B row table |