| From: | Decibel! <decibel(at)decibel(dot)org> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Bill Moran <wmoran(at)collaborativefusion(dot)com>, Kevin Kempter <kevin(at)kevinkempterllc(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: significant vacuum issues - looking for suggestions |
| Date: | 2007-08-27 22:04:39 |
| Message-ID: | 20070827220438.GR54309@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Aug 27, 2007 at 04:56:33PM -0500, 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?
How many drives? Write caching? 200G isn't *that* big for good drive
hardware, *IF* it's performing the way it should. You'd be surprised how
many arrays fall on their face even from a simple dd test.
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Kempter | 2007-08-27 22:06:00 | Re: significant vacuum issues - looking for suggestions |
| Previous Message | Kevin Kempter | 2007-08-27 22:03:52 | Re: significant vacuum issues - looking for suggestions |