From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Trevor Talbot" <quension(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance on 8CPU's and 32GB of RAM |
Date: | 2007-09-05 19:36:43 |
Message-ID: | dcc563d10709051236o60f852cdne392937704830200@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 9/5/07, Trevor Talbot <quension(at)gmail(dot)com> wrote:
> On 9/5/07, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> > On 9/5/07, Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca> wrote:
> > > > Right, additionally NTFS is really nothing to use on any serious disc
> > > > array.
> > >
> > > Do you mean that I will not see any big improvement if I upgrade the disk
> > > subsystem because the client is using NTFS (i.e. Windows)
> >
> > No, I think he's referring more to the lack of reliability of NTFS
> > compared to UFS / ZFS / JFS / XFS on unixen.
>
> Lack of reliability compared to _UFS_? Can you elaborate on this?
Oh, the other issue that NTFS still seems to suffer from that most
unix file systems have overcome is fragmentation. Since you can't
defrag a live system, you have to plan time to take down the db should
the NTFS partition for your db get overly fragmented.
And there's the issue that with windows / NTFS that when one process
opens a file for read, it locks it for all other users. This means
that things like virus scanners can cause odd, unpredictable failures
of your database.
From | Date | Subject | |
---|---|---|---|
Next Message | Ansgar -59cobalt- Wiechers | 2007-09-05 21:02:12 | Re: Performance on 8CPU's and 32GB of RAM |
Previous Message | Scott Marlowe | 2007-09-05 19:29:25 | Re: Performance on 8CPU's and 32GB of RAM |