Re: When does sequential performance matter in PG?

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

In response to

Browse pgsql-performance by date

  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