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