| From: | Greg Smith <gsmith(at)gregsmith(dot)com> | 
|---|---|
| To: | henk de wit <henk53602(at)hotmail(dot)com> | 
| Cc: | pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: When does sequential performance matter in PG? | 
| Date: | 2009-03-10 17:50:05 | 
| Message-ID: | alpine.GSO.2.01.0903101338560.14397@westnet.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Carey | 2009-03-10 18:01:00 | Re: When does sequential performance matter in PG? | 
| Previous Message | Tom Lane | 2009-03-10 17:20:47 | Re: Query much slower when run from postgres function |