On Wed, Sep 05, 2007 at 11:06:03AM -0400, Carlo Stonebanks wrote:
> Unfortunately, LINUX is not an option at this time. We looked into it; there
> is no *NIX expertise in the enterprise. However, I have raised this issue in
> various forums before, and when pressed no one was willing to say that "*
Scott,
Well, there've been a lot of issues with anti-virus and postgresql not
> getting along. I wonder if pgsql takes out a stronger lock, and when
> it can't get it then the failure happens. Not familiar enough with
> windows to do more than speculate.
without touching the file-concurrency i
On 9/7/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Scott Marlowe:
>
> > 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
* Scott Marlowe:
> 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.
I think most of them open the file in shared/ba
Carlo Stonebanks wrote:
Isn't it just easier to assume that Windows Server can't do anything right?
;-)
Well, avoiding the ;-) - people do, and its remarkably foolish of them. Its
a long-standing whinge that many people with a UNIX-background seem to
just assume that Windows sucks, but you
<<
If what you mean is that pg has a design that's heavily oriented towards
things that tend to
be cheap on POSIX and doesn't use the core Win32 features effectively,
then let's track
that as an optimisation opportunity for the Win32 port.
>>
Isn't it just easier to assume that Windows Server ca
James Mansion escribió:
> If what you mean is that pg has a design that's heavily oriented
> towards things that tend to be cheap on POSIX and doesn't use the core
> Win32 features effectively, then let's track that as an optimisation
> opportunity for the Win32 port.
Already done for 8.3 (actual
RFORM] Performance on 8CPU's and 32GB of RAM
Carlo Stonebanks wrote:
> Isn't it just easier to assume that Windows Server can't do anything
right?
> ;-)
>
>
Well, avoiding the ;-) - people do, and its remarkably foolish of them. Its
a long-standing whinge that many pe
On 9/6/07, James Mansion <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > 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
> > o
Scott Marlowe wrote:
Where unixes generally outperform windows is in starting up new
backends, better file systems, and handling very large shared_buffer
settings.
Why do you think that UNIX systems are better at handling large shared
buffers than Wndows?
32 bit Windows systems can suffer f
Scott Marlowe wrote:
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.
Can you provide some justification for this?
On 2007-09-05 Scott Marlowe wrote:
> On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
>> On 2007-09-05 Scott Marlowe wrote:
>>> On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
On 2007-09-05 Scott Marlowe wrote:
> And there's the issue that with windows / NT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carlo Stonebanks wrote:
> Unfortunately, LINUX is not an option at this time. We looked into it; there
> is no *NIX expertise in the enterprise. However, I have raised this issue in
> various forums before, and when pressed no one was willing to say th
On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
> On 2007-09-05 Scott Marlowe wrote:
> > On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
> >> On 2007-09-05 Scott Marlowe wrote:
> >>> And there's the issue that with windows / NTFS that when one process
> >>> opens a
On 2007-09-05 Scott Marlowe wrote:
> On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
>> On 2007-09-05 Scott Marlowe wrote:
>>> 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 thing
On Wed, 2007-09-05 at 14:36 -0500, Scott Marlowe wrote:
> On 9/5/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
> > On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > > On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > > > > Right, additionally NTFS is really nothing to use on any serio
On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote:
> On 2007-09-05 Scott Marlowe wrote:
> > 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, u
On 2007-09-05 Scott Marlowe wrote:
> 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.
Uh... what? Locking isn't done
On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
> > On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > > On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > > > > Right, additionally NTFS is really nothing to use on any serious d
On 9/5/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > > > Right, additionally NTFS is really nothing to use on any serious disc
> > > > array.
> > >
> > > Do you mean that I will not s
On 9/5/07, Trevor Talbot <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > > > Right, additionally NTFS is really nothing to use on any serious disc
> > > > array.
> > >
> > > Do you mean that I will not s
Trevor Talbot wrote:
>
> Lack of reliability compared to _UFS_? Can you elaborate on this?
What elaboration's needed? UFS seems to have one of the longest
histories of support from major vendors of any file system supported
on any OS (Solaris, HP-UX, SVR4, Tru64 Unix all use it).
Can you elab
On 9/5/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> 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 becau
On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> >> Large shared_buffers and Windows do not mix. Perhaps you should leave
> the shmem config low, so that the kernel can cache the file pages.
> <<
>
> Is there a problem BESIDES the one that used to cause windows to fail to
> allocate memory
Carlo Stonebanks wrote:
> >> It sounds like you will need a huge lot of vacuuming effort to keep up.
> Maybe you should lower autovac scale factors so that your tables are
> visited more frequently. A vacuum_delay of 40 sounds like too much
> though.
> <<
>
> Does autovacuum not impede performan
>> Large shared_buffers and Windows do not mix. Perhaps you should leave
the shmem config low, so that the kernel can cache the file pages.
<<
Is there a problem BESIDES the one that used to cause windows to fail to
allocate memory in blocks larger than 1.5GB?
The symptom of this problem was tha
On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> 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 ref
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)
---(end of broadcast)---
TIP 9: In
On 9/5/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> Unfortunately, LINUX is not an option at this time. We looked into it; there
> is no *NIX expertise in the enterprise. However, I have raised this issue in
> various forums before, and when pressed no one was willing to say that "*NIX
> *DEFI
ing RAID 1.
-Original Message-
From: Scott Marlowe [mailto:[EMAIL PROTECTED]
Sent: September 4, 2007 7:15 PM
To: Alvaro Herrera
Cc: Carlo Stonebanks; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Performance on 8CPU's and 32GB of RAM
On 9/4/07, Alvaro Herrera <[EMAIL PROTECTE
On 05.09.2007 01:15, Scott Marlowe wrote:
On 9/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Carlo Stonebanks wrote:
A client is moving their postgresql db to a brand new Windows 2003 x64
server with 2 quad cores and 32GB of RAM. It is a dedicated server to run
8.2.4.
Large shared_buffers an
On 9/4/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Carlo Stonebanks wrote:
> > A client is moving their postgresql db to a brand new Windows 2003 x64
> > server with 2 quad cores and 32GB of RAM. It is a dedicated server to run
> > 8.2.4.
>
> Large shared_buffers and Windows do not mix. Perhap
Carlo Stonebanks wrote:
> A client is moving their postgresql db to a brand new Windows 2003 x64
> server with 2 quad cores and 32GB of RAM. It is a dedicated server to run
> 8.2.4.
Large shared_buffers and Windows do not mix. Perhaps you should leave
the shmem config low, so that the kernel ca
On 9/4/07, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> A client is moving their postgresql db to a brand new Windows 2003 x64
> server with 2 quad cores and 32GB of RAM. It is a dedicated server to run
> 8.2.4.
And what does the drive subsystem look like? All that horsepower
isn't going to help
A client is moving their postgresql db to a brand new Windows 2003 x64
server with 2 quad cores and 32GB of RAM. It is a dedicated server to run
8.2.4.
The server typically will have less than 10 users. The primary use of this
server is to host a database that is continuously being updated by
35 matches
Mail list logo
