Re: New to PostgreSQL, performance considerations
От | Ron |
---|---|
Тема | Re: New to PostgreSQL, performance considerations |
Дата | |
Msg-id | E1GvBfR-0005f3-11@elasmtp-scoter.atl.sa.earthlink.net обсуждение исходный текст |
Ответ на | Re: New to PostgreSQL, performance considerations ("Luke Lonergan" <llonergan@greenplum.com>) |
Ответы |
Re: New to PostgreSQL, performance considerations
|
Список | 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: >>> >>> http://purefiction.net/paste/pgbench2.pdf >>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. > >Alexander. http://www.sun.com/servers/entry/x4100/features.xml 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. http://www.seagate.com/cda/products/discsales/index/1,,,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
В списке pgsql-performance по дате отправления: