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 *NIX
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 your
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
* 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
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 / NTFS that when one
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?
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
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
of your
Wow - it's nice to hear someone say that... out loud.
Thanks, you gave me hope!
-Original Message-
From: James Mansion [mailto:[EMAIL PROTECTED]
Sent: September 6, 2007 4:55 PM
To: Carlo Stonebanks
Cc: Scott Marlowe; Alvaro Herrera; pgsql-performance@postgresql.org
Subject: Re:
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 can't
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
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
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 and
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
*DEFINITELY* outperforms Windows for what my client is doing (or if
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
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:
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
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 that
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 performance while
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 in blocks
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 because the client is
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
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 see any big improvement
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 see any big improvement
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 disc
array.
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 by
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,
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 serious disc
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 things like virus
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 file for read,
-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 that
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
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 if
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 can
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. Perhaps you
35 matches
Mail list logo
