Re: pgbench--new transaction type

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench--new transaction type
Date: 2011-07-26 01:35:55
Message-ID: 4E2E19FB.5040600@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/25/2011 08:12 PM, Jeff Janes wrote:
> In the absence of -s and presence of -f, :scale gets set to 1, rather
> than to "select count(*) from pgbench_branches".
>
> I don't think it is nice to rely on people to correctly specify -s. I
> would like to change -f so that in the absence of -s it uses the same
> scale as -S, etc., do. But that would probably be too backwards
> incompatible to be an acceptable change.
>

Auto-detecting scale only works if you have a database populated with
the pgbench tables. You can use "pgbench -f" to run arbitrary bits of
SQL, using pgbench as the driver program for all sorts of benchmarking
tasks against other data sets. For example, at
http://projects.2ndquadrant.it/sites/default/files/pgbench-intro.pdf I
show how to use it for testing how fast INSERT statements of various
sizes can execute.

The very concept of a "scale" may not make sense for other data sets
that pgbench will happily run against when using "-f". The only sort of
heuristic I have considered adding here when running in that mode is:

1) Check if pgbench_branches exists.
2) If so, count the records to derive a scale, as currently done in the
non "-f" cases
3) Should that scale not match the value of "-s", issue a warning.

You have to assume anyone sophisticated enough to be playing with "-f"
may be doing something the program doesn't expect or understand, and let
them do that without trying to "fix" what may be intentional behavior.
But a check for the most common mistake made in this area wouldn't
bother people who aren't using pgbench in its original form at all,
while it would help those new to the program from screwing this up.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-07-26 01:41:53 Re: write scalability
Previous Message Bruce Momjian 2011-07-26 01:29:59 Re: Problem with pg_upgrade's directory write check on Windows