Skip site navigation (1) Skip section navigation (2)

Re: New to PostgreSQL, performance considerations

From: Ron <rjpeace(at)earthlink(dot)net>
To: Alexander Staubo <alex(at)purefiction(dot)net>
Cc: Postgresql Performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: New to PostgreSQL, performance considerations
Date: 2006-12-15 11:55:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
At 04:54 AM 12/15/2006, Alexander Staubo wrote:
>On Dec 15, 2006, at 04:09 , Ron wrote:
>>At 07:27 PM 12/14/2006, Alexander Staubo wrote:
>>>Sorry, I neglected to include the pertinent graph:
>>In fact, your graph suggests that using arch specific options in 
>>addition to -O3 actually =hurts= performance.
>According to the tech staff, this is a Sun X4100 with a two-drive 
>RAID 1 volume. No idea about the make of the hard drives.

So we are dealing with a 1U 1-4S (which means 1-8C) AMD Kx box with 
up to 32GB of ECC RAM (DDR2 ?) and 2 Seagate 2.5" SAS HDs.,,,00.html?interface=SAS

My bet is the X4100 contains one of the 3 models of Cheetah 
15K.4's.  A simple du, dkinfo, whatever, will tell you which.

I'm looking more closely into exactly what the various gcc -O 
optimizations do on Kx's as well.
64b vs 32b gets x86 compatible code access to ~ 2x as many registers; 
and MMX or SSE instructions get you access to not only more 
registers, but wider ones as well.

As one wit has noted, "all optimization is an exercise in caching." 
(Terje Mathisen- one of the better assembler coders on the planet.)

It seems unusual that code generation options which give access to 
more registers would ever result in slower code...
Ron Peacetree

In response to


pgsql-performance by date

Next:From: Gregory StarkDate: 2006-12-15 12:15:59
Previous:From: Dimitri FontaineDate: 2006-12-15 11:24:35

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group