From: Kevin Kempter <kevin@kevinkempterllc.com>
To: pgsql-performance@postgresql.org
Subject: Re: significant vacuum issues - looking for suggestions
Date: Mon, 27 Aug 2007 16:00:01 -0600
User-Agent: KMail/1.9.7
References: <200708241357.23629.kevin@kevinkempterllc.com>
	<20070827210041.GN54309@nasby.net>
	<46D30240.EE98.0025.0@wicourts.gov>
In-Reply-To: <46D30240.EE98.0025.0@wicourts.gov>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200708271600.02053.kevin@kevinkempterllc.com>

On Monday 27 August 2007 15:56:33 Kevin Grittner wrote:
> >>> Decibel! <decibel@decibel.org> 08/27/07 4:00 PM >>>
> >>>
> > > > They're running  version 8.1.4
> >
> > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT *
> > FROM bloated_table? That would likely be much faster than messing around
> > with pg_dump.
>
> He wanted to upgrade to 8.2.4.  CREATE TABLE AS won't get him there.
>
> > > > They're running  version 8.1.4 on 4-way dell boxes
> > > > with 4Gig of memory on each box attached to RAID-10 disk arrays.
> >
> > What kind of disk hardware is this running on? A good raid 10 array with
> > write caching should be able to handle a 200G database fairly well
>
> What other details were you looking for?
>
> -Kevin
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

I decided to fix this table first - did so by creating a new table, running a 
select from insert into and renaming the orig table to old_XXX and then 
renamed the new table to the orig table's name.

I'll drop the orig table once I'm sure there are no data issues.

I'm planning to setup a new file system layout for the box(es) and try to do a 
pg_dump | psql for the upgrade.