On Fri, 30 Nov 2007, Wolfgang Keller wrote:
it was impossible for me to find a similarly priced
(Linux-/*BSD/Intel/AMD-)equivalent to my PowerMac G5 over here at the
time when I bought it.
The problem from my perspective is the common complaint that Apple doesn't
ship an inexpensive desktop
At 6:15 PM -0500 11/30/07, Greg Smith wrote:
On Fri, 30 Nov 2007, Guido Neitzer wrote:
Actually - In our test if just used with a similar load as pgbench
(e.g. typical web applications) Mac OS X 10.4.7 performed better
then Yellow Dog Linux (I was testing with G5 hardware) on the same
hardwa
On Fri, 30 Nov 2007, Lincoln Yeoh wrote:
Anecdotal - I have found "smart" raid controllers to fail more often than
dumb scsi controllers (or even SATA/PATA controllers), and some seem more
failure prone than semi-decent operating systems.
You'd need to name some names here for this to mean to
On Fri, 30 Nov 2007, Guido Neitzer wrote:
Actually - In our test if just used with a similar load as pgbench (e.g.
typical web applications) Mac OS X 10.4.7 performed better then Yellow Dog
Linux (I was testing with G5 hardware) on the same hardware as soon as more
than about 90 concurrent cl
On 30.11.2007, at 04:48, Wolfgang Keller wrote:
LSI drivers are not available for MacOS X on PowerMacs? Ouch.
The problem is that they suck as they can't to channel bundling for
higher trough-put to a single disk array.
[not your comment, but referred there]
and Mac OS X, PostgreSQL has e
At 09:09 PM 11/30/2007, Trevor Talbot wrote:
The controller always exists, so it's not moving a point of failure;
if a controller goes you've lost the disk anyway.
Anecdotal - I have found "smart" raid controllers to fail more often
than dumb scsi controllers (or even SATA/PATA controllers),
On 11/30/07, Wolfgang Keller <[EMAIL PROTECTED]> wrote:
> > For example, if you have an application that needs high
> > database write throughput, to make that work well with PostgreSQL you
> > must have a controller with a battery backed cache.
> Hmm, what would be the difference compared to ple
Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows
(2000, XP, Vista etc.) on the same hardware? And Linux to
(Free-/Net-/whatever) BSD?
Apple hardware gets so expensive for some types of database
configurations that such a comparision doesn't even make a lot of
sense.
So far my
On Thu, Nov 29, 2007 at 11:04:38PM -0600, Wes wrote:
> Regarding the various kernel bottlenecks, have there been any tests with
> Google's malloc (libtcmalloc)?
PostgreSQL has its own allocator on top of malloc already. tcmalloc is
optimised for many small allocations, whereas postgres only requ
On Thu, 29 Nov 2007, Wes wrote:
Perhaps PostgreSQL isn't heavily threaded enough to make a difference
PostgreSQL doesn't use threads at all; it forks processes. See 1.14 in
http://www.postgresql.org/docs/faqs.FAQ_DEV.html
The benchmark that got us looking at this was a MySQL benchmark show
Regarding the various kernel bottlenecks, have there been any tests with
Google's malloc (libtcmalloc)? Perhaps PostgreSQL isn't heavily threaded
enough to make a difference, but on one of our heavily threaded applications
(unrelated to Postgres), it made a night and day difference. Instead of
me
> Only under Solaris. With Linux or BSD on it it ran pretty well. I
> had a Sparc 20 running RH 7.2 back in the day (or whatever the last
> version of RH that ran on sparc was) that spanked an Ultra-2 running
> slowalrus with twice the memory and hard drives handily.
>
> Solaris has gotten much
On Wed, Nov 28, 2007 at 10:33:08AM -0800, Trevor Talbot wrote:
> On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Trevor Talbot wrote:
> > > On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
> > >> There is at least one other bottleneck, probably more than one. Context
> > >> sw
On 11/28/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007 09:53:34 -0800
> "Trevor Talbot" <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
> > > > > Yes, very much so. Windows lacks the fork() concept, which is
> > > > > what makes Postgre
On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
> > On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >> There is at least one other bottleneck, probably more than one. Context
> >> switching between processes is a lot more expensive than on Unix (given
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 28 Nov 2007 09:53:34 -0800
"Trevor Talbot" <[EMAIL PROTECTED]> wrote:
> On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
> > > > Yes, very much so. Windows lacks the fork() con
Trevor Talbot wrote:
> On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
Yes, very much so. Windows lacks the fork() concept, which is what makes
PostgreSQL much slower there.
>>> So grossly slower process creation would kil
On 11/28/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
> > > Yes, very much so. Windows lacks the fork() concept, which is what makes
> > > PostgreSQL much slower there.
> >
> > So grossly slower process creation would kill postgres connectio
Ron Johnson wrote:
> On 11/28/07 11:13, Magnus Hagander wrote:
>> On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
Yes, very much so. Windows lacks the fork() concept, which is what makes
PostgreSQL much slower there.
>>> So grossly slower process creation would kill postgres connecti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/07 11:13, Magnus Hagander wrote:
> On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
>>> Yes, very much so. Windows lacks the fork() concept, which is what makes
>>> PostgreSQL much slower there.
>> So grossly slower process creation would
On Wed, 2007-11-28 at 07:29 -0700, Scott Ribe wrote:
> > Yes, very much so. Windows lacks the fork() concept, which is what makes
> > PostgreSQL much slower there.
>
> So grossly slower process creation would kill postgres connection times. But
> what about the cases where persistent connections
> Yes, very much so. Windows lacks the fork() concept, which is what makes
> PostgreSQL much slower there.
So grossly slower process creation would kill postgres connection times. But
what about the cases where persistent connections are used? Is it the case
also that Windows has a performance bot
On 11/27/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > Kind of. Mach is still running underneath (and a lot of the app APIs
> > use it directly) but there is a BSD 'personality' above it which
> > (AIUI) is big parts of FreeBSD ported to run on Mach. So
On Tue, 27 Nov 2007, Ron Johnson wrote:
There was a benchmark in Feb 2007 which demonstrated that FBSD 7.0
scaled *better* than Linux 2.6 after 4 CPUs.
http://jeffr-tech.livejournal.com/5705.html
Turns out that there was/is a bug in glibc's malloc(). Don't know
if it's been fixed yet.
Last I
On Tue, 27 Nov 2007, Scott Ribe wrote:
IIRC, it was later established that during those tests they had fsync
enabled on OS X and disabled on Linux.
You recall correctly but I'm guessing you didn't keep up with the
investigation there; I was tempted to bring this up in that last message
but w
On Tue, Nov 27, 2007 at 05:01:06PM -0700, Scott Ribe wrote:
> > In general, you can expect any Unix based OS, which includes MacOS X, to
> > perform noticeably better than Windows for PostgreSQL.
>
> Is that really true of BSD UNIXen??? I've certainly heard it's true of
> Linux. But with BSD you h
Doug McNaught <[EMAIL PROTECTED]> writes:
> On Nov 27, 2007, at 8:36 PM, Gregory Stark wrote:
>> I think (but I'm not sure) that the kernel in OSX comes from BSD.
> Kind of. Mach is still running underneath (and a lot of the app APIs
> use it directly) but there is a BSD 'personality' above it
> There are claims this
> is improved in current systems (Leopard + Intel), but the margin was so
> big before...
IIRC, it was later established that during those tests they had fsync
enabled on OS X and disabled on Linux.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-056
> Kind of. Mach is still running underneath (and a lot of the app APIs
> use it directly) but there is a BSD 'personality' above it which
> (AIUI) is big parts of FreeBSD ported to run on Mach.
Right. Also, to be clear, OS X is not a true microkernel architecture. They
took the "division of respo
Only under Solaris. With Linux or BSD on it it ran pretty well. I
had a Sparc 20 running RH 7.2 back in the day (or whatever the last
version of RH that ran on sparc was) that spanked an Ultra-2 running
slowalrus with twice the memory and hard drives handily.
Solaris has gotten much better sinc
On Nov 27, 2007 8:05 PM, Ron Johnson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/27/07 19:35, Greg Smith wrote:
> [snip]
> > to you. The minute performance becomes a serious concern, you'd be much
> > better off with Linux, one of the BSDs that's not hobb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/07 19:35, Greg Smith wrote:
[snip]
> to you. The minute performance becomes a serious concern, you'd be much
> better off with Linux, one of the BSDs that's not hobbled by using the
> Mach kernel, or one of the more serious UNIXes like Solari
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/07 19:36, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
[snip]
>
> That was true of the traditional BSD 4.3 and 4.4 design. However when people
> refer to "BSD" these days they're referring to one of the major derivativ
On Nov 27, 2007, at 8:36 PM, Gregory Stark wrote:
I think (but I'm not sure) that the kernel in OSX comes from BSD.
Kind of. Mach is still running underneath (and a lot of the app APIs
use it directly) but there is a BSD 'personality' above it which
(AIUI) is big parts of FreeBSD ported
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Tue, 27 Nov 2007 17:01:06 -0700
> Scott Ribe <[EMAIL PROTECTED]> wrote:
>
>> > In general, you can expect any Unix based OS, which includes MacOS
>> > X, to perform noticeably better than Windows for PostgreSQL.
>>
>> Is that really true of BSD U
On Tue, 27 Nov 2007, Wolfgang Keller wrote:
Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000,
XP, Vista etc.) on the same hardware? And Linux to (Free-/Net-/whatever)
BSD?
Apple hardware gets so expensive for some types of database configurations
that such a comparision
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/07 18:01, Scott Ribe wrote:
>> In general, you can expect any Unix based OS, which includes MacOS X, to
>> perform noticeably better than Windows for PostgreSQL.
>
> Is that really true of BSD UNIXen??? I've certainly heard it's true of
> Lin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 17:01:06 -0700
Scott Ribe <[EMAIL PROTECTED]> wrote:
> > In general, you can expect any Unix based OS, which includes MacOS
> > X, to perform noticeably better than Windows for PostgreSQL.
>
> Is that really true of BSD UNIXen???
> In general, you can expect any Unix based OS, which includes MacOS X, to
> perform noticeably better than Windows for PostgreSQL.
Is that really true of BSD UNIXen??? I've certainly heard it's true of
Linux. But with BSD you have the "kernel funnel" which can severely limit
multitasking, regardl
On Tue, 2007-11-27 at 11:11 +0100, Wolfgang Keller wrote:
> Hello,
>
> sorry for "butting in", but I'm just curious...
>
> > resolution?
> >
> > http://archives.postgresql.org/pgsql-general/2007-11/msg00946.php
> >
> > conclusion?
> >
> > Mac was still pretty slow in comparison
>
> Anyway, how
Hello,
sorry for "butting in", but I'm just curious...
resolution?
http://archives.postgresql.org/pgsql-general/2007-11/msg00946.php
conclusion?
Mac was still pretty slow in comparison
Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000,
XP, Vista etc.) on the same hard
Hello,
sorry for "butting in", but I'm just curious...
resolution?
http://archives.postgresql.org/pgsql-general/2007-11/msg00946.php
conclusion?
Mac was still pretty slow in comparison
Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows (2000,
XP, Vista etc.) on the same hard
On Mon, 2007-11-26 at 17:37 -0600, Wes wrote:
> On 11/13/07 10:02 AM, "Scott Ribe" <[EMAIL PROTECTED]> wrote:
>
> > What you're referring to must be that the kernel was essentially
> > single-threaded, with a single "kernel-funnel" lock. (Because the OS
> > certainly supported threads, and it was
On 11/13/07 10:02 AM, "Scott Ribe" <[EMAIL PROTECTED]> wrote:
> What you're referring to must be that the kernel was essentially
> single-threaded, with a single "kernel-funnel" lock. (Because the OS
> certainly supported threads, and it was certainly possible to write
> highly-threaded applicatio
Thanks to all for the help - and the sanity check. The problem was in
the test and not in the configuration.
We were using a particularly difficult query as a reference (and fully
understanding that it is a two-dimensional alternative to a proper
benchmark). On our test system each run was with
> my understanding was that the lack of threading on OSX made it
> especially poor for a DB server
What you're referring to must be that the kernel was essentially
single-threaded, with a single "kernel-funnel" lock. (Because the OS
certainly supported threads, and it was certainly possible to wri
On Fri, 2007-11-09 at 23:55 -0500, Mark Niedzielski wrote:
> Our developers run on MacBook Pros w/ 2G memory and our production
> hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5. The
> Macs perform common and complex Postgres operations in about half the
> time of our unloaded pr
On Mon, Nov 12, 2007 at 05:02:52PM -0500, Vivek Khera wrote:
> On Nov 12, 2007, at 12:29 PM, Sam Mason wrote:
> >You only need a 64bit address space when each process wants to see
> >more than ~3GB of RAM.
>
> And how exactly do you get that on a 32-bit CPU?
I didn't mean to suggest you could. Yo
On Nov 12, 2007, at 12:01 PM, Greg Smith wrote:
Not the Mac OS BSD. Last time I looked into this OS X was still
dramatically slower than Linux on things like process creation.
On MacOS X, that's the Mach kernel doing process creation, not
anything BSD-ish at all. The BSD flavor of MacOS
On Nov 12, 2007, at 12:29 PM, Sam Mason wrote:
You only need a 64bit address space when each process wants to see
more
than ~3GB of RAM.
And how exactly do you get that on a 32-bit CPU? Even with PAE
(shudders from memories of expanded/extended RAM in the DOS days), you
still have a 32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Nov 2007 10:47:29 -0700
Steve Wampler <[EMAIL PROTECTED]> wrote:
> Sam Mason wrote:
> > And what's the performance hit of using native 64bit code? I'd
> > guess similar, moving twice as much data around with each pointer
> > has got to aff
On Mon, Nov 12, 2007 at 11:46:12AM -0600, Scott Marlowe wrote:
> On Nov 12, 2007 11:37 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > And what's the performance hit of using native 64bit code? I'd guess
> > similar, moving twice as much data around with each pointer has got to
> > affect things.
>
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Nov 12, 2007 11:37 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
>> And what's the performance hit of using native 64bit code? I'd guess
>> similar, moving twice as much data around with each pointer has got to
>> affect things.
>
> That's not been my
Sam Mason wrote:
And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.
That's probably difficult to predict. Since the architecture is 64-bits,
it shouldn't cost any more to move a 64-bit poin
On Nov 12, 2007 11:37 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 12, 2007 at 11:31:59AM -0600, Scott Marlowe wrote:
> > On Nov 12, 2007 11:29 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > > You don't need a 32bit kernel to support 8GB of memory should you? As
> > > long as the kernel sup
Scott Marlowe wrote:
On Nov 12, 2007 11:29 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see mo
On Mon, Nov 12, 2007 at 11:31:59AM -0600, Scott Marlowe wrote:
> On Nov 12, 2007 11:29 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > You don't need a 32bit kernel to support 8GB of memory should you? As
> > long as the kernel supports PAE that should be enough to make use of it.
> > You only need a
On Nov 12, 2007 11:29 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 12, 2007 at 10:14:46AM -0700, Steve Wampler wrote:
> > Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
> > to support the 8GB) or a 64-bit? And which was PostgreSQL compiled for?
>
> You don't need
On Mon, Nov 12, 2007 at 10:14:46AM -0700, Steve Wampler wrote:
> Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
> to support the 8GB) or a 64-bit? And which was PostgreSQL compiled for?
You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kerne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 09 Nov 2007 23:55:59 -0500
Mark Niedzielski <[EMAIL PROTECTED]> wrote:
>
> Our developers run on MacBook Pros w/ 2G memory and our production
> hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5.
> The Macs perform common and c
On Fri, 9 Nov 2007, Mark Niedzielski wrote:
The Macs perform common and complex Postgres operations in about half
the time of our unloaded production hardware.
Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
to support the 8GB) or a 64-bit? And which was PostgreSQL compi
On Fri, 9 Nov 2007, Mark Niedzielski wrote:
The Macs perform common and complex Postgres operations in about half
the time of our unloaded production hardware.
Are they write intensive? If so, it may be possible that the Macs are
buffering disk writes while production server isn't. It's oft
On Nov 9, 2007 10:55 PM, Mark Niedzielski <[EMAIL PROTECTED]> wrote:
>
> Our developers run on MacBook Pros w/ 2G memory and our production
> hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5. The
> Macs perform common and complex Postgres operations in about half the
> time of our
Our developers run on MacBook Pros w/ 2G memory and our production
hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5. The
Macs perform common and complex Postgres operations in about half the
time of our unloaded production hardware. We've compared configurations
and the producti
64 matches
Mail list logo
