Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-performance by date

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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group