Re: Large tables (was: RAID 0 not as fast as

From: Markus Schaber <schabi(at)logix-tt(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Large tables (was: RAID 0 not as fast as
Date: 2006-09-20 08:09:04
Message-ID: 4510F720.5010007@logix-tt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Cosimo Streppone 2006-09-20 09:09:23 Update on high concurrency OLTP application and Postgres 8 tuning
Previous Message Jeff Davis 2006-09-19 23:54:01 Re: Pipelined functions in Postgres