On Thu, 14 Jan 2010 16:35:53 -0600
Dave Crooke dcro...@gmail.com wrote:
For any given database engine, regardless of the marketing and support
stance, there is only one true primary enterprise OS platform that
most big mission critical sites use, and is the best supported and
most stable
On Fri, Jan 15, 2010 at 8:10 AM, Tony McC af...@btinternet.com wrote:
most stable platform for that RDBMS. For Oracle, that's HP-UX (but 10
years ago, it was Solaris). For PostgreSQL, it's Linux.
I am interested in this response and am wondering if this is just
Dave's opinion or some sort of
On Fri, Jan 15, 2010 at 11:10 AM, Tony McC af...@btinternet.com wrote:
what is it about Linux specifically (as
contrasted with other Unix-like OSes, especially Open Source ones) that
makes it particularly suitable for running PostgreSQL?
Nothing that I know of.
...Robert
--
Sent via
Richard Broersma richard.broer...@gmail.com writes:
On Fri, Jan 15, 2010 at 8:10 AM, Tony McC af...@btinternet.com wrote:
most stable platform for that RDBMS. For Oracle, that's HP-UX (but 10
years ago, it was Solaris). For PostgreSQL, it's Linux.
I am interested in this response and am
Tom Lane wrote:
Given the Linux kernel hackers' apparent disinterest in fixing their
OOM kill policy or making write barriers work well (or at all, with
LVM), I think arguing that Linux is the best database platform requires
a certain amount of suspension of disbelief.
Don't forget the
On Fri, Jan 15, 2010 at 11:28 AM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
Given the Linux kernel hackers' apparent disinterest in fixing their
OOM kill policy or making write barriers work well (or at all, with
LVM), I think arguing that Linux is the best database platform
Scott Marlowe scott.marl...@gmail.com wrote:
I will say that XFS seems to be a very stable file system, and we
use it for some of our databases with no problems at all. But
most of our stuff sits on ext3 because it's stable and reliable
and fast enough.
Our PostgreSQL data directories are
This is the second time I've heard that PG shared buffer on Windows doesn't
matter ... I'd like to understand the reasoning behind that claim, and why
it differs from other DB servers.
though that's much less important for Pg than for most other things, as
Pg uses a
Dave Crooke wrote:
My reasoning goes like this:
a. there is a significant performance benefit to using a large
proportion of memory as in-process DB server cache instead of OS level
block / filesystem cache
b. the only way to do so on modern hardware (i.e. 4GB) is with a
64-bit binary
c.
Dave Crooke dcro...@gmail.com writes:
This is the second time I've heard that PG shared buffer on Windows doesn't
matter ... I'd like to understand the reasoning behind that claim, and why
it differs from other DB servers.
AFAIK we don't really understand why, but the experimental evidence is
My client just informed me that new hardware is available for our DB server.
. Intel Core 2 Quads Quad
. 48 GB RAM
. 4 Disk RAID drive (RAID level TBD)
I have put the ugly details of what we do with our DB below, as well as the
postgres.conf settings. But, to summarize: we have a PostgreSQL
I'll bite
1. In general, RAID-10 is the only suitable RAID configuration for a
database. The decision making comes in how many drives, and splitting stuff
up into LUNs (like putting pg_xlog on its own LUN).
2. None of the above - you're asking the wrong question really. PostgreSQL
is open
On 15/01/2010 6:35 AM, Dave Crooke wrote:
I'll bite
1. In general, RAID-10 is the only suitable RAID configuration for a
database. The decision making comes in how many drives, and splitting
stuff up into LUNs (like putting pg_xlog on its own LUN).
The biggest problem with Postgres
13 matches
Mail list logo
