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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
