Re: [PATCH] pgbench: new feature allowing to launch shell commands

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] pgbench: new feature allowing to launch shell commands
Date: 2009-09-23 02:14:30
Message-ID: c64c5f8b0909221914s66408c5et4163b296ca14a3d1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

See attached a patch of this setshell feature.

If you use in a script file something like:
/setshell param_set setshellparam.sh
pgbench reads from the shell script setshellparam.sh the first output value,
verifies if it is an integer, then manages it as a pgbench parameter.
I did not take into account you 4th and 5th arguments, so it is just a basic
implementation.

Depending on the statistical model you want to use for you pgbench tests, it
is possible to add other parameters as on the call prototype you proposed.

Regards,

Michael

On Wed, Sep 23, 2009 at 8:17 AM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> On Tue, 22 Sep 2009, Michael Paquier wrote:
>
> Besides, you can also make tests without 2pc transactions, such as:
>> \shell ls -ll /home/ioltas/usr/pgsql/data
>> END;
>>
>
> I think that demonstrating the pgbench shell feature with this 2PC example
> is working against your patch being even considered, much less accepted.
> It's way too complicated, and the idea you're pouplarizing with it that the
> script should save whatever it does in the external filesystem is messy.
> You'll need a simpler one that still accomplishes something useful that can
> go into the docs no matter what, the problems with prepared transactions
> you're reporting in your messages are just the beginning of issues that come
> from presenting this as the "hello, world" of how to use the shell feature.
>
> Most of the cases I can think of for situations where I'd like to call the
> shell in a pgbench script require doing something useful with the result
> that is returned. For example, when I'm picking a row at random, I often
> want to skew which row that is, to simulate the common real-world situation
> where a fraction of customers generate most of the transactions (the Pareto
> principle).
>
> What I'd consider closer to a useful implementation of this feature is that
> you could call a shell script and use the first line of its output to set
> one of the pgbench internal variables. The range of return codes is way too
> limited for those to help here. Here's what that might look like, assuming
> "skewedrand" is our script that does that given the range it needs to
> operate over:
>
> \set nbranches :scale
> \set ntellers 10 * :scale
> \set naccounts 100000 * :scale
> \setshell aid skewedrand 1 :naccounts
> SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
>
> (I'm not sure if setshell would need to interpret the output as an integer
> for this to work right, there may be some int vs. string considerations
> here)
>
> If you got something like that working first before moving onto these more
> complicated examples and I think you'll have an easier time of things.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>

--
Michael Paquier

NTT OSSC

Attachment Content-Type Size
postgresql-8.4.0-pgbenchsetshell.patch text/x-patch 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2009-09-23 02:18:59 latest hstore patch
Previous Message Josh Berkus 2009-09-23 00:35:36 Re: Join optimization for inheritance tables