From: Luke Lonergan <llonergan@greenplum.com>
To: mark@mark.mielke.cc
Cc: Bucky Jordan <bjordan@lumeta.com>
Cc: Spiegelberg, Greg <gspiegelberg@cranel.com>
Cc: Joshua Drake <jd@commandprompt.com>
Cc: Craig A. James <cjames@modgraph-usa.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Large tables (was: RAID 0 not as fast as
Date: Mon, 18 Sep 2006 21:01:45 -0700
Message-ID: <C134B9B9.31741%llonergan@greenplum.com> (raw)
In-Reply-To: <20060919034547.GA24692@mark.mielke.cc>
Mark,
On 9/18/06 8:45 PM, "mark@mark.mielke.cc" <mark@mark.mielke.cc> wrote:
> Does a tool exist yet to time this for a particular configuration?
We're considering building this into ANALYZE on a per-table basis. The
basic approach times sequential access in page rate, then random seeks as
page rate and takes the ratio of same.
Since PG's heap scan is single threaded, the seek rate is equivalent to a
single disk (even though RAID arrays may have many spindles), the typical
random seek rates are around 100-200 seeks per second from within the
backend. That means that as sequential scan performance increases, such as
happens when using large RAID arrays, the random_page_cost will range from
50 to 300 linearly as the size of the RAID array increases.
- Luke
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: llonergan@greenplum.com, mark@mark.mielke.cc, bjordan@lumeta.com, gspiegelberg@cranel.com, jd@commandprompt.com, cjames@modgraph-usa.com
Subject: Re: Large tables (was: RAID 0 not as fast as
In-Reply-To: <C134B9B9.31741%llonergan@greenplum.com>
* 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