From: | Ian Westmacott <ianw(at)intellivid(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: VACUUM and read-mostly tables |
Date: | 2005-04-05 17:56:05 |
Message-ID: | 1112723765.8115.119.camel@spectre.intellivid.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, 2005-04-05 at 11:39, Jim C. Nasby wrote:
> On Tue, Apr 05, 2005 at 11:13:06AM -0400, Ian Westmacott wrote:
> > On Tue, 2005-04-05 at 00:41, Jim C. Nasby wrote:
> > > We'll only answer if you do a write-up on your database. :P
> > >
> > > Seriously, those are some seriously big numbers. What else is the
> > > database doing? What hardware is it running on?
> >
> >
> > We run on a dual 3.2GHz P4 with 2GB RAM, but are still
> > finalizing the storage hardware. We've tried various
> > flavors of RAID, filesystems and volume management (and
> > are anxious to try out tablespaces in 8). We've found
> > fragmentation to be our largest limiting factor. XFS
> > helps with that, and seems to provide the highest
> > sustained throughput on raw tables, but its not the end
> > of the story since fragmentation is still high.
>
> What else is the database doing besides the inserts?
A proportionally small number of updates, no deletes, and
a set of moderately complex queries.
> And if UFS is available for linux you should might try it.
Would UFS help the fragmentation issue? We have seen ext3
allocating blocks in 2-4 pages, while XFS manages 8-16
pages.
Thanks,
--Ian
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-05 18:26:54 | Re: VACUUM and read-mostly tables |
Previous Message | Ian Westmacott | 2005-04-05 17:47:08 | Re: VACUUM and read-mostly tables |