Re: pgbench: new feature allowing to launch shell commands

Takahiro Itagaki wrote:
> Heavily cleaned up patch attached. Please review it.
>   
This is almost there.  The refactoring work you both did is exactly how 
I was hoping this would end up looking, code-wise, and the feature set 
is basically feature complete except for one small UI concern I have.

Attached is an updated version of my skewed-select.sql test program, 
adjusted to take advantage of the now supported syntax.  Note that in 
order to run this properly, you need to pass the database scale into 
pgbench when you run it like this:

  pgbench -T 10 -j 4 -c 8 -s 10 -f skewed-select.sql pgbench

Because when you use a custom "-f" script, :scale isn't set otherwise.

In the current version of the patch, you can do this:

  \setshell aid skewed-acct.pl :naccounts

But you can't do this:

  \setshell :aid skewed-acct.pl :naccounts

What's worse is that you don't get an error in that second case--it just 
doesn't set the variable.  I thought this was fixed by one of Michael's 
versions here, so maybe this is a regression from the other clean-up?  
Since all the other ways you interact with this type of variable in 
pgbench require the ":", not supporting it in this context seems like a 
recipe for weird problems for those trying to use it.

If we can get an updated version where you can use either syntax for the 
variable name passed to setshell, this one will be ready for commit I 
think.  I was tempted to fix the bug myself, but I seem to be doing 
better as a tester on this patch rather than working on its 
development.  Everything else--docs, code--looks pretty good now. 

Only thing we might add is a warning that you're going to completely 
tank your pgbench results by using the high-overhead shell command if 
your test would otherwise be limited by CPU.  This feature is only 
really useful as far as performance testing goes if you're using it on 
an I/O bound test.  I have some more pgbench hints to apply at some 
point in the future, so it wouldn't be problem to skip this for now; I 
can bundle it into that section later.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com