Re: significant vacuum issues - looking for suggestions

From: Kevin Kempter <kevin(at)kevinkempterllc(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: significant vacuum issues - looking for suggestions
Date: 2007-08-27 22:00:01
Message-ID: 200708271600.02053.kevin@kevinkempterllc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Monday 27 August 2007 15:56:33 Kevin Grittner wrote:
> >>> Decibel! <decibel(at)decibel(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Kempter 2007-08-27 22:03:52 Re: significant vacuum issues - looking for suggestions
Previous Message Kevin Grittner 2007-08-27 21:56:33 Re: significant vacuum issues - looking for suggestions