On 06/20/2012 03:22 PM, Peter Geoghegan wrote:
> The situation would be made a lot better if we could just find a way
> to generalise pgbench a little bit more. I'm thinking about a facility
> for specifying new tables in scripts, with a moderate degree of
> flexibility as to their definition, data, and the distribution of that
> data.
That's probably excess scope creep for this CF though. And converting
this new script to use a longer name like --test would be a useful
forward step for such a larger plan anyway.
I think there's some useful value to breaking out the existing test
scripts into files too, rather than all of them being embedded in the
source code. While there's not any pressure to reclaim existing
switches like -S and -N, having those just be shortcuts for a
"--test=pgbench-select-only.sql" form would make sure that external
script facility worked right. I think there's some value to making it
easier for people to copy the built-in scripts and hack on them too.
The main sticky point I see here that really needs to be improved now,
to turn any of the built-in ones to external scripts, is flagging how to
handle the database scale. Right now the built-in scripts set :scale
based on counting pgbench_branches, while external ones run with "-f" do
not. What things like pgbench-tools end up doing is manually doing that
count and then passing it in with "-s <scale>". That's annoying, and if
this is getting refactored I'd like to improve that too. Getting that
logic cleanly while being backward compatible is a bit complicated; I'm
going to think about that for a bit.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com