Tom Lane wrote:
As of the 9.0 release, it's possible to run pgbench in a "multi thread" mode, and if you forced the subprocess rather than thread model it looks like the select() limit would be per subprocess rather than global. So I think you could get above the FD_SETSIZE limit with a bit of hacking if you were using 9.0's pgbench. No chance with 8.3 though.
I believe David can do this easily enough by compiling a 9.0 source code tree with the "--disable-thread-safety" option. That's the simplest way to force the pgbench client to build itself using the multi-process model, rather than the multi-threaded one.
It's kind of futile to run pgbench simulating much more than a hundred or two clients before 9.0 anyway. Without multiple workers, you're likely to just run into the process switching limitations within pgbench itself rather than testing server performance usefully. I've watched the older pgbench program fail to come close to saturating an 8 core server without running into its own limitations first.
You might run a 9.0 pgbench client against an 8.3 server though, if you did the whole thing starting from pgbench database initialization over again--the built-in tables like "accounts" changed to "pgbench_accounts" in 8.4. That might work, can't recall any changes that would prevent it; but as I haven't tested it yet I can't say for sure.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
