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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
