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: | 44088FE9-4AA9-4FD6-AE8F-34560A6401BA@purefiction.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
flags.
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?
Alexander.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2006-12-16 00:06:56 | Re: New to PostgreSQL, performance considerations |
Previous Message | Bruno Wolff III | 2006-12-15 21:12:47 | Re: File Systems Compared |