Skip site navigation (1) Skip section navigation (2)

Re: 64-bit vs 32-bit performance ... backwards?

From: "Alex Turner" <armtuk(at)gmail(dot)com>
To: "Steve Atkins" <steve(at)blighty(dot)com>
Cc: "Pgsql-Performance ((E-mail))" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Date: 2006-06-13 02:26:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Anyone who has tried x86-64 linux knows what a royal pain in the ass it
is.   They didn't do anything sensible, like just make the whole OS 64 bit,
no, they had to split it up, and put 64-bit libs in a new directory /lib64.
This means that a great many applications don't know to check in there for
libs, and don't compile pleasantly, php is one among them.  I forget what
others, it's been awhile now.  Of course if you actualy want to use more
than 4gig RAM in a pleasant way, it's pretty much essential.


On 6/12/06, Steve Atkins <steve(at)blighty(dot)com> wrote:
> On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote:
> >
> >> Empirically... postgresql built for 64 bits is marginally slower
> >> than that built
> >> for a 32 bit api on sparc. None of my customers have found 64 bit x86
> >> systems to be suitable for production use, yet, so I've not tested
> >> on any
> >> of those architectures.
> >
> > Really? All of our customers are migrating to Opteron and I have
> > many that have been using Opteron for over 12 months happily.
> An Opteron is 64 bit capable; that doesn't mean you have to run 64 bit
> code on it.
> Mine're mostly reasonably conservative users, with hundreds of machines
> to support. Using 64 bit capable hardware, such as Opterons, is one
> thing,
> but using an entirely different linux installation and userspace
> code, say, is
> a much bigger change in support terms. In the extreme case it makes no
> sense to double your OS support overheads to get a single digit
> percentage
> performance improvement on one database system.
> That's not to say that linux/x86-64 isn't production ready for some
> users, just
> that it's not necessarily a good operational decision for my
> customers. Given
> my internal workloads aren't really stressing the hardware they're on
> I don't
> have much incentive to benchmark x86-64 yet - by the time the numbers
> might be useful to me we'll be on a different postgresql, likely a
> different
> gcc/icc and so on.
> Cheers,
>    Steve
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

In response to


pgsql-performance by date

Next:From: Christopher BrowneDate: 2006-06-13 02:31:57
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Previous:From: markDate: 2006-06-13 02:16:27
Subject: Re: 64-bit vs 32-bit performance ... backwards?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group