Date: Tue, 10 Mar 2009 13:50:05 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: henk de wit <henk53602@hotmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: When does sequential performance matter in PG?
In-Reply-To: <COL104-W4301D2DDC445A99E55E086F5A10@phx.gbl>
Message-ID: <alpine.GSO.2.01.0903101338560.14397@westnet.com>
References: <COL104-W4301D2DDC445A99E55E086F5A10@phx.gbl>
User-Agent: Alpine 2.01 (GSO 1184 2008-12-16)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 10 Mar 2009, henk de wit wrote:

> Now I wonder if there is any situation in which sequential IO 
> performance comes into play. E.g. perhaps during a tablescan on a 
> non-fragmented table, or during a backup or restore?

If you're doing a sequential scan of data that was loaded in a fairly 
large batch, you can approach reading at the sequential I/O rate of the 
drives.  Doing a backup using pg_dump is one situation where you might 
actually do that.

Unless your disk performance is really weak, restores in PostgreSQL are 
usually CPU bound right now.  There's a new parallel restore feature in 
8.4 that may make sequential write performance a more likely upper bound 
to run into, assuming your table structure is amenable to loading in 
parallel (situations with just one giant table won't benefit as much).

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD