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: | Raw Message | Whole Thread | 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 |