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.