Re: random observations while testing with a 1,8B row

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

In response to

Browse pgsql-hackers by date

  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