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 elf_i386" \
AS="/usr/bin/gcc -m32 -Wa,--32 -D__ASSEMBLY__ -traditional" \
CC="/usr/bin/gcc -m32" \
CFLAGS="-O3 -funroll-loops -fno-strict-aliasing -pipe -mcpu=opteron
-march=opteron -mfpmath=sse -msse2" \
./configure --prefix=<pgsql-path>
J. Andrew Rogers schrieb:
The short story is that for us 64-bit PostgreSQL on Opterons is
typically something like 20% faster than 32-bit on the same, and *much*
faster than P4 Xeon systems they nominally compete with. AMD64 is a
more efficient architecture than x86 in a number of ways, and the
Opteron has enviable memory latency and bandwidth that make it an
extremely efficient database workhorse. x86->AMD64 is not a word-width
migration, it is a different architecture cleverly designed to be
efficiently compatible with x86. In addition to things like a more
RISC-like register set, AMD64 uses a different floating point
architecture that is more efficient than the old x87.
I did a few test in the past with 64-bit PostgreSQL and 32-bit
PostgreSQL and the 32-bit version was always faster.
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 smaller with PostgreSQL 8.1.
Cheers
Sven.
diff -Naur postgresql-8.1.4.orig/src/include/storage/s_lock.h postgresql-8.1.4/src/include/storage/s_lock.h
--- postgresql-8.1.4.orig/src/include/storage/s_lock.h 2005-10-11 22:41:32.000000000 +0200
+++ postgresql-8.1.4/src/include/storage/s_lock.h 2006-05-31 09:19:04.000000000 +0200
@@ -125,12 +125,9 @@
* extra test appears to be a small loss on some x86 platforms and a small
* win on others; it's by no means clear that we should keep it.
*/
+ /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
__asm__ __volatile__(
- " cmpb $0,%1 \n"
- " jne 1f \n"
- " lock \n"
" xchgb %0,%1 \n"
- "1: \n"
: "+q"(_res), "+m"(*lock)
:
: "memory", "cc");
@@ -189,8 +186,8 @@
* is a huge loss. On EM64T, it appears to be a wash or small loss,
* so we needn't bother to try to distinguish the sub-architectures.
*/
+ /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
__asm__ __volatile__(
- " lock \n"
" xchgb %0,%1 \n"
: "+q"(_res), "+m"(*lock)
:
