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
J. Andrew Rogers wrote:
We have been using PostgreSQL on Opteron servers almost since the
Opteron was first released, running both 32-bit and 64-bit versions of
Linux. Both 32-bit and 64-bit versions have been bulletproof for us,
with the usual stability I've become accustomed to with both
Installation of a 32-bit PostgreSQL on a 64-bit Linux like RHEL 4 is
very easy. Make sure that you have installed all needed 32-bit libs and
devel packages.
Here is an example to call configure to get a 32-bit PostgreSQL:
CXX=/usr/bin/g++ -m32 \
CPP=/usr/bin/gcc -m32 -E \
LD=/usr/bin/ld -m
On Tue, 13 Jun 2006 04:26:05 +0200, Alex Turner [EMAIL PROTECTED] wrote:
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
Sven,
On 6/13/06 2:04 AM, Sven Geisler [EMAIL PROTECTED] wrote:
Please find attached a small patch with does apply a change to the
x86_64 part also to the i386 part of src/include/storage/s_lock.h.
Without this change the performance of PostgreSQL 8.0 was horrible on a
Opteron. The effect is
Luke
Luke Lonergan schrieb:
On 6/13/06 2:04 AM, Sven Geisler [EMAIL PROTECTED] wrote:
Please find attached a small patch with does apply a change to the
x86_64 part also to the i386 part of src/include/storage/s_lock.h.
Without this change the performance of PostgreSQL 8.0 was horrible on a
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Nis Jorgensen)
wrote:
J. Andrew Rogers wrote:
We have been using PostgreSQL on Opteron servers almost since the
Opteron was first released, running both 32-bit and 64-bit versions of
Linux. Both 32-bit and 64-bit versions have
Sven,
On 6/13/06 5:03 AM, Sven Geisler [EMAIL PROTECTED] wrote:
Yes, I know. We had a problem last year with the performance of the
Opteron. We have started the futex patch to resolve the issue. The futex
patch itself did have no effect, but there was a side effect because the
futex patch
Luke
Luke Lonergan schrieb:
Sven,
On 6/13/06 5:03 AM, Sven Geisler [EMAIL PROTECTED] wrote:
Yes, I know. We had a problem last year with the performance of the
Opteron. We have started the futex patch to resolve the issue. The futex
patch itself did have no effect, but there was a side effect
Sven,
On 6/13/06 5:46 AM, Sven Geisler [EMAIL PROTECTED] wrote:
You already get this change if you compile PostgreSQL 8.1.x in x86_64
(64-bit mode).
I see, so I think your point with the patch is to make the 32-bit compiled
version benefit as well.
- Luke
---(end
Luke,
Luke Lonergan schrieb:
On 6/13/06 5:46 AM, Sven Geisler [EMAIL PROTECTED] wrote:
You already get this change if you compile PostgreSQL 8.1.x in x86_64
(64-bit mode).
I see, so I think your point with the patch is to make the 32-bit compiled
version benefit as well.
Yup. I think you
Josh Berkus wrote:
Folks,
In which case, why was 64-bit such a big deal?
We had this discussion with 16/32 bit too, back in those 286/386 times...
Not too many 16bit apps left now :-)
Regards,
Andreas
---(end of broadcast)---
TIP 9: In
On Jun 13, 2006, at 1:40 AM, Nis Jorgensen wrote:
Since you sound like you have done extensive testing:
Do you have any data regarding whether to enable hyperthreading or
not?
I realize that this may be highly dependant on the OS, application and
number of CPUs, but I would be interested in
On Mon, Jun 12, 2006 at 05:19:46PM -0600, David Boreham wrote:
What they are saying is strictly true : 64-bit pointers tend to increase
the working set size
of an application vs. 32-bit pointers. This means that any caches will
have somewhat lower
hit ratio. Also the bytes/s between the CPU
On Mon, Jun 12, 2006 at 08:04:41PM -0400, Stephen Frost wrote:
don't think). This is because Postgres lets the OS handle most of the
cacheing, so as long as your OS can see all the memory you have in the
Actually, in 8.1.x I've seen some big wins from greatly increasing the
amount of
Hi all!
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than the 32-bit version. Since the guys of EDB
are
Anthony,
I'm curious if anyone can back this up or debunk it. It's about
the polar opposite of everything I've heard from every other database
vendor for the past several years, and would be quite an eye-opener for
me.
I generally see a 20% free gain in performance on 64-bit (Opteron,
Anthony Presley wrote:
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than the 32-bit version. Since the
On Jun 12, 2006, at 3:28 PM, Anthony Presley wrote:
Hi all!
I had an interesting discussion today w/ an Enterprise DB developer
and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY
Anthony Presley [EMAIL PROTECTED] writes:
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than the 32-bit
* Anthony Presley ([EMAIL PROTECTED]) wrote:
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than the
Anthony Presley [EMAIL PROTECTED] wrote:
Hi all!
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than
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
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
Title: Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?
Opteron is ~20% faster at executing code in 64-bit mode than 32-bit because of the extra registers made available with their 64-bit mode:
http://www.tomshardware.com/2003/04/22/duel_of_the_titans/page7.html
Doubling the GPRs
I've been trying to track this stuff - in fact, I'll likely be
switching from AMD32 to AMD64 in the next few weeks.
I believe I have a handle on the + vs - of 64-bit. It makes sense that
full 64-bit would be slower. At an extreme it halfs the amount of
available memory or doubles the required
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
[EMAIL PROTECTED] (Anthony Presley) wrote:
Hi all!
I had an interesting discussion today w/ an Enterprise DB developer and
sales person, and was told, twice, that the 64-bit linux version of
Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
is SIGNIFICANTLY SLOWER than
Alex Turner [EMAIL PROTECTED] writes:
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.
Actually, there's nothing wrong
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Alex Turner)
wrote:
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
Mark,
On 6/12/06 7:16 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I haven't. I'm meaning to take a look. Within registers, 64-bit should
be equal speed to 32-bit. Outside the registers, it would make sense
to only deal with the lower 32-bits where 32-bits is all that is
required.
The
On Jun 12, 2006, at 19:44, Tom Lane wrote:
(Personally, if I'd designed it, the libraries would actually live in
/usr/lib32 and /usr/lib64, and /usr/lib would be a symlink to
whichever
you needed it to be at the moment. Likewise for /usr/bin.)
/me nominates Tom to create a Linux
Alex Turner wrote:
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
Folks,
FWIW, the applications where I did direct 32 / 64 comparison were
a) several data warehouse tests, with databases 100GB
b) computation-heavy applications (such as a complex calendaring app)
And, as others have pointed out, I wasn't comparing generics; I was comparing
Athalon/Xeon to
34 matches
Mail list logo
