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 |
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 |