Skip site navigation (1) Skip section navigation (2)

Re: pgbench post-connection command

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench post-connection command
Date: 2012-01-13 13:10:27
Message-ID: 4F102D43.9050700@2ndQuadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-13 13:12:16
Subject: Re: CLONE TABLE DATA TO <new_table>
Previous:From: Simon RiggsDate: 2012-01-13 13:05:47
Subject: pgsql: Correctly initialise shared recoveryLastRecPtr in recovery.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group