On Nov 26, 2010, at 2:30 PM, Greg Smith wrote: > > In addition to the memory issues, there's also thread CPU scheduling > involved here. Ideally the benchmark would pin each thread to a single > core and keep it there for the runtime of the test, but it's not there > yet. I suspect one source of variation at odd numbers of threads > involves processes that bounce between CPUs more than in the more even > cases. > Depends on what you're interested in. Postgres doesn't pin threads to processors. Postgres doesn't use threads. A STREAM benchmark that used multiple processes, with half SYSV shared and half in-process memory access, would be better. How the OS schedules the processes and memory access is critical. One server might score higher on an optimized 'pin the processes' STREAM test, but be slower in the real world for Postgres because its not testing anything that Postgres can do. > -- > Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD > PostgreSQL Training, Services and Support www.2ndQuadrant.us > "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
