Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Large tables (was: RAID 0 not as fast as
- From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
- To: mark(at)mark(dot)mielke(dot)cc
- Cc: "Bucky Jordan" <bjordan(at)lumeta(dot)com>, "Spiegelberg, Greg" <gspiegelberg(at)cranel(dot)com>, "Joshua Drake" <jd(at)commandprompt(dot)com>, "Craig A. James" <cjames(at)modgraph-usa(dot)com>, pgsql-performance(at)postgresql(dot)org
- Subject: Re: Large tables (was: RAID 0 not as fast as
- Date: Mon, 18 Sep 2006 21:01:45 -0700
Mark, On 9/18/06 8:45 PM, "mark(at)mark(dot)mielke(dot)cc" <mark(at)mark(dot)mielke(dot)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
- Follow-Ups:
- Re: Large tables (was: RAID 0 not as fast as
- From: Markus Schaber
- Re: Large tables (was: RAID 0 not as fast as
- References:
- Prev by Date: Re: Large tables (was: RAID 0 not as fast as expected)
- Next by Date: Re: High CPU Load
- Previous by thread: Re: Large tables (was: RAID 0 not as fast as expected)
- Next by thread: Re: Large tables (was: RAID 0 not as fast as
- Indexes: