Re: New to PostgreSQL, performance considerations - Mailing list pgsql-performance
From | Daniel van Ham Colchete |
---|---|
Subject | Re: New to PostgreSQL, performance considerations |
Date | |
Msg-id | 8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com Whole thread Raw |
In response to | Re: New to PostgreSQL, performance considerations (Michael Stone <mstone+postgres@mathom.us>) |
Responses |
Re: New to PostgreSQL, performance considerations
Re: New to PostgreSQL, performance considerations Re: New to PostgreSQL, performance considerations |
List | pgsql-performance |
Mike, unfortunally I don't have any benchmarks right now. Doing something like this with the same machine would be a 2-day work (at least). Installing a Gentoo and putting it to run well is not a quick task (although is easy). But, trust me on this one. It's worth it. Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms: btree, hashes, checksums, strings functions, etc... And you have a lot of ways to compile it into binary code. Now you have Pentium4's vectorization that allow you to run plenty of instructions in paralell, but AMD doesn't have this. Intel also have SSE2 that makes double-precision floatpoint operations a lot faster, AMD also doesn't have this (at least on 32bits). Now imagine that you're RedHat and that you have to deliver one CD to AMD and Intel servers. That means you can't use any AMD-specific or Intel-specific tecnology at the binary level. Things can get worse. If you take a look at GCC's code (at gcc/config/i386/i386.c), you'll see that GCC knows what runs faster on each processor. Let-me give an example with the FDIV and FSQRT instructions: ARCH - FDIV - FSQRT (costs relative to an ADD) i386: 88 - 122 i486: 73 - 83 pentium: 39 - 70 k6: 56 - 56 Athlon: 24 - 35 K8: 19 - 35 Pentium4: 43 - 43 Nocona: 40 - 44 Imagine that you are GCC and that you have two options in front of you: you can use FSQRT or FDIV plus 20 ADD/SUB. If you are on an Pentium situation you should use the second option. But on a Pentium4 or on a Athlon you should choose for the first one. This was only an example, nowadays you would have to choose between: 387, 3dNow, 3dNow+, SSE, SSE2, ... With this info, GCC knows how to choose the best ways to doing things to each processor. When you are compiling to an generic i586 (like Fedora and RedHat), them you are using pentium's timings. An example that I know of: it's impossible to run my software at a high demanding customer without compiling it to the it's processor (I make 5 compilations on every release). Using Intel's Compiler for Intel's processors makes things even faster, but it is not free and the "how fast" part really depends on your application is coded. With 64bits processors, AMD and Intel restarted the process and everyone has SSE2 (but not SSE3). Even so, the timings are also very diferent. Best regards Daniel On 12/11/06, Michael Stone <mstone+postgres@mathom.us> wrote: > On Sun, Dec 10, 2006 at 11:02:44PM -0200, Daniel van Ham Colchete wrote: > >I'm using Gentoo Linux, so all my libraries (including glibc that is > >very important to PostgreSQL), and all my softwares are compiled with > >good CFLAG options to my processor ("-O2 march=athlon-xp (...)"). My > >Linux is not an Intel-AMD binary compatible turtle like > >Fedora/RedHat/SUSE/... It's really important to have your GLIBC > >compiled for your processor. It is essencial for performance. > > Please, point to the benchmarks that demonstrate this for a postgres > application. > > Mike Stone > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
pgsql-performance by date: