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

Re: New to PostgreSQL, performance considerations

From: Alexander Staubo <alex(at)purefiction(dot)net>
To: Ron <rjpeace(at)earthlink(dot)net>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: New to PostgreSQL, performance considerations
Date: 2006-12-15 22:29:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Dec 15, 2006, at 17:53 , Ron wrote:

> At 09:50 AM 12/15/2006, Greg Smith wrote:
>> On Fri, 15 Dec 2006, Merlin Moncure wrote:
>>> The slower is probably due to the unroll loops switch which can  
>>> actually hurt code due to the larger footprint (less cache  
>>> coherency).
>> The cache issues are so important with current processors that I'd  
>> suggest throwing -Os (optimize for size) into the mix people  
>> test.  That one may stack usefully with -O2, but probably not with  
>> -O3 (3 includes optimizations that increase code size).
> -Os
> Optimize for size. -Os enables all -O2 optimizations that do not  
> typically increase code size. It also performs further  
> optimizations designed to reduce code size.

So far I have been compiling PostgreSQL and running my pgbench script  
manually, but this makes me want to modify my script to run pgbench  
automatically using all possible permutations of a set of compiler  

Last I tried GCC to produce 32-bit code on this Opteron system,  
though, it complained about the lack of a compiler; can I persuade it  
to generate 32-bit code (or 32-bit pointers for that matter) without  
going the cross-compilation route?


In response to


pgsql-performance by date

Next:From: Michael StoneDate: 2006-12-16 00:06:56
Subject: Re: New to PostgreSQL, performance considerations
Previous:From: Bruno Wolff IIIDate: 2006-12-15 21:12:47
Subject: Re: File Systems Compared

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