Re: New to PostgreSQL, performance considerations
От | Alexander Staubo |
---|---|
Тема | Re: New to PostgreSQL, performance considerations |
Дата | |
Msg-id | 44088FE9-4AA9-4FD6-AE8F-34560A6401BA@purefiction.net обсуждение исходный текст |
Ответ на | Re: New to PostgreSQL, performance considerations (Ron <rjpeace@earthlink.net>) |
Ответы |
Re: New to PostgreSQL, performance considerations
|
Список | 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.
В списке pgsql-performance по дате отправления: