From: Markus Schaber <schabi@logix-tt.com>
To: pgsql-performance@postgresql.org
Subject: Re: Large tables (was: RAID 0 not as fast as
Date: Wed, 20 Sep 2006 10:09:04 +0200
Message-ID: <4510F720.5010007@logix-tt.com> (raw)
In-Reply-To: <C134B9B9.31741%llonergan@greenplum.com>
References: <C134B9B9.31741%llonergan@greenplum.com>
Hi, Luke,
Luke Lonergan wrote:
> 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.
Do you think that adding some posix_fadvise() calls to the backend to
pre-fetch some blocks into the OS cache asynchroneously could improve
that situation?
I could imagine that e. G. index bitmap scans could profit in the heap
fetching stage by fadvise()ing the next few blocks.
Maybe asynchroneous I/O could be used for the same benefit, but
posix_fadvise is less() intrusive, and can easily be #define'd out on
platforms that don't support it.
Combine this with the Linux Kernel I/O Scheduler patches (readahead
improvements) that were discussed here in summer...
Regards,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
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: schabi@logix-tt.com
Subject: Re: Large tables (was: RAID 0 not as fast as
In-Reply-To: <4510F720.5010007@logix-tt.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