There's one part of this that's still fuzzy in the spec I'd like to
clarify, if nothing else than for my own memory's sake--as the person
most likely to review a random pgbench patch. Simon gave an example
like this:
pgbench -x "SET synchronous_commit = off"
All are agreed this should take the name of a script instead on the
command line:
pgbench -x "nosync"
And execute that script as part of the initial setup to every connection.
Now: "nosync" might be a shell script called similarly to \shell.
That's more flexible in terms of its ability to do complicated setup
things, say a more ambitious iteration along the 'create a table per
connection' trail. But it can't really prime connection parameters
anymore, so that's pretty worthless.
It seems it must then be a pgbench script like "-f" specifies instead.
It will execute SQL and pgbench's \ meta commands. And I think that's
OK so long as two things are nailed down (as in, tested to work and
hopefully alluded to in the documentation):
1) The pgbench connection setup script can call \shell or \setshell.
Then we've got a backdoor to also handle the complicated external script
situation.
2) The connection setup script can set variables and they will still be
active after passing control to the main test script. Returning to the
"table per connection" sort of idea, that might be:
setup:
\setrandom tablename 1 100
CREATE TABLE test_:tablename;
main:
SELECT count(*) FROM test_tablename;
I would use this feature all the time once it was added, so glad to see
the idea pop up. I also have a long standing personal TODO to write a
doc update in this area: suggest how to use environment variables to
sneak settings into things. There's been a couple of ideas for pgbench
proposed that were blocked with "you can already do that setting PGxxx
before calling pgbench". That is true, but not obvious, and
periodically it get reinvented again.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com