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 guys of EDB
are PostgreSQL ..... has anyone seen that the 64-bit is slower than the
32-bit version?
I was told that the added 32-bits puts a "strain" and extra "overhead"
on the processor / etc.... which actually slows down the pointers and
necessary back-end "stuff" on the database.
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.
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 and memory will be higher
due to moving those larger pointers.
In the case of a 32-bit OS this also applies to the kernel so the effect
will be system-wide.
However, an application that needs to work on > around 2G of data will
in the end be
much faster 64-bit due to reduced I/O (it can keep more of the data in
memory).
I worked on porting a large database application from 32-bit to 64-bit. One
of our customers required us to retain the 32-bit version because of
this phenomenon.
In measurements I conducted on that application, the performance
difference wasn't
great (10% or so), but it was measurable. This was with Sun Sparc hardware.
It is possible that more modern CPU designs have more efficient 64-bit
implementation than 32-bit, so the opposite might be seen too.
Whether or not PG would show the same thing I can't say for sure.
Probably it would though.