>>> Grzegorz Jaœkiewicz <gryz...@gmail.com> wrote: > Scalability is something that is affected by everything, and fixing > this makes sens as much as looking at possible fixes to make raids > more scalable, which is looked at by someone else I think. > So please, don't say that this doesn't make sense because he tested it > against ram disc. That was precisely the point of exercise. I'm probably more inclined to believe that his change may have merit than many here, but I can't accept anything based on this test until someone answers the question, so far ignored by all responses, of where the bottleneck is at the low end which allows linear scalability up to 1000 users (which I assume means connections). I'm particularly inclined to be suspicious of this test since my own benchmarks, with real applications replaying real URL requests from a production website that gets millions of hits per day, show that response time and throughput are improved by using a connection pool with queuing to limit the concurrent active queries. My skepticism is not helped by the fact that in a previous discussion with someone about performance as connections are increased, this point was covered by introducing a "primitive" connection pool -- which used a one second sleep for a thread if the maximum number of connections were already in use, rather than proper queuing and semaphores. That really gives no clue how performance would be with a real connection pool. -Kevin
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
