Re: [PERFORMANCE] expanding to SAN: which portion best to move

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To:
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORMANCE] expanding to SAN: which portion best to move
Date: 2011-05-17 09:47:09
Message-ID: 4DD2441D.8040500@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On 05/17/2011 03:00 PM, Robert Klemme wrote:

> The main point is that you do not benefit from the larger IO bandwidth
> if access patterns do not permit parallel access to both disks (e.g.
> because you first need to read index blocks in order to know the table
> blocks to read).

This makes me wonder if Pg attempts to pre-fetch blocks of interest for
areas where I/O needs can be known in advance, while there's still other
works or other I/O to do. For example, pre-fetching for the next
iteration of a nested loop while still executing the prior one. Is it
even possible?

I'm guessing not, because (AFAIK) Pg uses only synchronous blocking I/O,
and with that there isn't really a way to pre-fetch w/o threads or
helper processes. Linux (at least) supports buffered async I/O, so it'd
be possible to submit such prefetch requests ... on modern Linux
kernels. Portably doing so, though - not so much.

--
Craig Ringer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Cédric Villemain 2011-05-17 10:06:31 Re: Memcached for Database server
Previous Message Gerhard Hintermayer 2011-05-17 09:30:10 Re: ordering of join using ON expression = any (array)

Browse pgsql-performance by date

  From Date Subject
Next Message Cédric Villemain 2011-05-17 10:13:21 Re: [PERFORMANCE] expanding to SAN: which portion best to move
Previous Message Clemens Eisserer 2011-05-17 07:38:55 Re: hash semi join caused by "IN (select ...)"