head	1.21;
access;
symbols
	REL7_4_29:1.9.4.1
	REL8_0_25:1.10
	REL8_1_21:1.12
	REL8_2_17:1.15
	REL7_4_28:1.9.4.1
	REL8_0_24:1.10
	REL8_1_20:1.12
	REL8_2_16:1.15
	REL7_4_27:1.9.4.1
	REL8_0_23:1.10
	REL8_1_19:1.12
	REL8_2_15:1.15
	REL7_4_26:1.9.4.1
	REL8_0_22:1.10
	REL8_1_18:1.12
	REL8_2_14:1.15
	REL7_4_25:1.9.4.1
	REL8_0_21:1.10
	REL8_1_17:1.12
	REL8_2_13:1.15
	REL7_4_24:1.9.4.1
	REL8_0_20:1.10
	REL8_1_16:1.12
	REL8_2_12:1.15
	REL7_4_23:1.9.4.1
	REL8_0_19:1.10
	REL8_1_15:1.12
	REL8_2_11:1.15
	REL7_4_22:1.9.4.1
	REL8_0_18:1.10
	REL8_1_14:1.12
	REL8_2_10:1.15
	REL7_4_21:1.9.4.1
	REL8_0_17:1.10
	REL8_1_13:1.12
	REL8_2_9:1.15
	REL7_4_20:1.9.4.1
	REL8_0_16:1.10
	REL8_1_12:1.12
	REL8_2_8:1.15
	REL8_2_7:1.15
	REL7_3_21:1.7
	REL7_4_19:1.9.4.1
	REL8_0_15:1.10
	REL8_1_11:1.12
	REL8_2_6:1.15
	REL8_3_BETA2:1.20
	REL8_3_BETA1:1.20
	REL7_3_20:1.7
	REL7_4_18:1.9.4.1
	REL8_0_14:1.10
	REL8_1_10:1.12
	REL8_2_5:1.15
	REL7_3_19:1.7
	REL7_4_17:1.9.4.1
	REL8_0_13:1.10
	REL8_1_9:1.12
	REL8_2_4:1.15
	REL8_0_12:1.10
	REL8_1_8:1.12
	REL8_2_3:1.15
	REL7_3_18:1.7
	REL7_4_16:1.9.4.1
	REL8_0_11:1.10
	REL8_1_7:1.12
	REL8_2_2:1.15
	REL8_0_10:1.10
	REL8_1_6:1.12
	REL8_2_1:1.15
	REL7_4_15:1.9.4.1
	REL7_3_17:1.7
	REL8_2_STABLE:1.15.0.2
	REL8_2_0:1.15
	REL8_2_RC1:1.15
	REL8_2_BETA3:1.15
	REL8_2_BETA2:1.15
	REL8_1_5:1.12
	REL8_0_9:1.10
	REL7_4_14:1.9.4.1
	REL7_3_16:1.7
	REL8_2_BETA1:1.14
	REL7_3_15:1.7
	REL7_4_13:1.9.4.1
	REL8_0_8:1.10
	REL8_1_4:1.12
	REL7_3_14:1.7
	REL7_4_12:1.9.4.1
	REL8_0_7:1.10
	REL8_1_3:1.12
	REL7_3_13:1.7
	REL7_4_11:1.9.4.1
	REL8_0_6:1.10
	REL8_1_2:1.12
	REL7_3_12:1.7
	REL7_4_10:1.9.4.1
	REL8_0_5:1.10
	REL8_1_1:1.12
	REL8_1_STABLE:1.12.0.2
	REL8_1_0:1.12
	REL8_1_0RC1:1.12
	REL8_1_0BETA4:1.12
	REL8_1_0BETA3:1.12
	REL7_3_11:1.7
	REL7_4_9:1.9.4.1
	REL8_0_4:1.10
	REL8_1_0BETA2:1.10
	REL8_1_0BETA1:1.10
	REL7_2_8:1.4
	REL7_3_10:1.7
	REL7_4_8:1.9.4.1
	REL8_0_3:1.10
	REL8_0_2:1.10
	REL7_2_7:1.4
	REL7_3_9:1.7
	REL7_4_7:1.9.4.1
	REL8_0_1:1.10
	REL8_0_STABLE:1.10.0.4
	REL8_0_0:1.10.0.2
	REL8_0_0RC5:1.10
	REL8_0_0RC4:1.10
	REL8_0_0RC3:1.10
	REL8_0_0RC2:1.10
	REL8_0_0RC1:1.10
	REL8_0_0BETA5:1.10
	REL8_0_0BETA4:1.10
	REL7_4_6:1.9.4.1
	REL7_3_8:1.7
	REL7_2_6:1.4
	REL8_0_0BETA3:1.10
	REL8_0_0BETA2:1.10
	REL7_2_5:1.4
	REL7_4_5:1.9.4.1
	REL7_3_7:1.7
	REL7_4_4:1.9.4.1
	REL8_0_0BETA1:1.10
	REL7_4_3:1.9.4.1
	REL7_4_2:1.9.4.1
	REL7_3_6:1.7
	REL7_4_1:1.9.4.1
	REL7_3_5:1.7
	REL7_4:1.9
	REL7_4_RC2:1.9
	REL7_4_STABLE:1.9.0.4
	REL7_4_RC1:1.9
	REL7_4_BETA5:1.9
	REL7_4_BETA4:1.9
	REL7_4_BETA3:1.9
	REL7_4_BETA2:1.9
	WIN32_DEV:1.9.0.2
	REL7_4_BETA1:1.9
	REL7_3_4:1.7
	REL7_3_2:1.7
	REL7_2_4:1.4
	REL7_3_STABLE:1.7.0.2
	REL7_2_3:1.4
	REL7_2_STABLE:1.4.0.2
	REL7_2:1.4
	REL7_2_RC2:1.4
	REL7_2_RC1:1.4
	REL7_2_BETA5:1.4
	REL7_2_BETA4:1.4
	REL7_2_BETA3:1.4
	REL7_2_BETA2:1.4
	REL7_2_BETA1:1.4
	REL7_1_2:1.2
	REL7_1_STABLE:1.2.0.2
	REL7_1_BETA:1.1
	REL7_1_BETA3:1.1
	REL7_1_BETA2:1.1
	REL7_1:1.2;
locks; strict;
comment	@# @;


1.21
date	2007.11.10.23.30.46;	author momjian;	state dead;
branches;
next	1.20;

1.20
date	2007.07.06.20.17.02;	author wieck;	state Exp;
branches;
next	1.19;

1.19
date	2007.07.06.13.36.55;	author wieck;	state Exp;
branches;
next	1.18;

1.18
date	2007.04.08.01.15.07;	author ishii;	state Exp;
branches;
next	1.17;

1.17
date	2007.04.06.09.16.15;	author ishii;	state Exp;
branches;
next	1.16;

1.16
date	2007.04.06.08.49.44;	author ishii;	state Exp;
branches;
next	1.15;

1.15
date	2006.10.21.06.31.28;	author ishii;	state Exp;
branches;
next	1.14;

1.14
date	2006.09.13.00.39.19;	author ishii;	state Exp;
branches;
next	1.13;

1.13
date	2006.07.26.07.24.50;	author ishii;	state Exp;
branches;
next	1.12;

1.12
date	2005.10.04.13.40.45;	author ishii;	state Exp;
branches;
next	1.11;

1.11
date	2005.09.29.13.44.25;	author ishii;	state Exp;
branches;
next	1.10;

1.10
date	2003.11.26.06.53.18;	author ishii;	state Exp;
branches;
next	1.9;

1.9
date	2003.06.10.09.07.15;	author ishii;	state Exp;
branches
	1.9.4.1;
next	1.8;

1.8
date	2002.11.27.19.26.10;	author tgl;	state Exp;
branches;
next	1.7;

1.7
date	2002.07.20.03.02.01;	author ishii;	state Exp;
branches;
next	1.6;

1.6
date	2002.05.20.05.07.28;	author ishii;	state Exp;
branches;
next	1.5;

1.5
date	2002.02.24.00.17.57;	author ishii;	state Exp;
branches;
next	1.4;

1.4
date	2001.10.24.08.07.19;	author ishii;	state Exp;
branches;
next	1.3;

1.3
date	2001.09.09.03.15.56;	author ishii;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.16.21.41.53;	author tgl;	state Exp;
branches;
next	1.1;

1.1
date	2000.06.19.14.02.03;	author momjian;	state Exp;
branches;
next	;

1.9.4.1
date	2003.11.26.06.48.52;	author ishii;	state Exp;
branches;
next	;


desc
@@


1.21
log
@Move most /contrib README files into SGML.  Some still need conversion
or will never be converted.
@
text
@$PostgreSQL: pgsql/contrib/pgbench/README.pgbench,v 1.20 2007/07/06 20:17:02 wieck Exp $

pgbench README

o What is pgbench?

  pgbench is a simple program to run a benchmark test. pgbench is a
  client application of PostgreSQL and runs with PostgreSQL only. It
  performs lots of small and simple transactions including
  SELECT/UPDATE/INSERT operations then calculates number of
  transactions successfully completed within a second (transactions
  per second, tps). Targeting data includes a table with at least 100k
  tuples.

  Example outputs from pgbench look like:

	number of clients: 4
	number of transactions per client: 100
	number of processed transactions: 400/400
	tps = 19.875015(including connections establishing)
	tps = 20.098827(excluding connections establishing)

  Similar program called "JDBCBench" already exists, but it requires
  Java that may not be available on every platform. Moreover some
  people concerned about the overhead of Java that might lead
  inaccurate results. So I decided to write in pure C, and named
  it "pgbench."

o features of pgbench

  - pgbench is written in C using libpq only. So it is very portable
    and easy to install.

  - pgbench can simulate concurrent connections using asynchronous
    capability of libpq. No threading is required.

o How to install pgbench

 $make
 $make install

o How to use pgbench?

  (1) (optional)Initialize database by:

	pgbench -i <dbname>

      where <dbname> is the name of database. pgbench uses four tables
      accounts, branches, history and tellers. These tables will be
      destroyed. Be very careful if you have tables having same
      names. Default test data contains:

	table		# of tuples
	-------------------------
	branches	1
	tellers		10
	accounts	100000
	history		0

	You can increase the number of tuples by using -s option. branches,
	tellers and accounts tables are created with a fillfactor which is
	set using -F option. See below.

  (2) Run the benchmark test

	pgbench <dbname>

      The default configuration is:

	number of clients: 1
	number of transactions per client: 10

o options

  pgbench has number of options.

	-h hostname
		hostname where the backend is running. If this option
		is omitted, pgbench will connect to the localhost via
		Unix domain socket.

	-p port
		the port number that the backend is accepting. default is
		libpq's default, usually 5432.

	-c number_of_clients
		Number of clients simulated. default is 1.

	-t number_of_transactions
		Number of transactions each client runs. default is 10.

	-s scaling_factor
		this should be used with -i (initialize) option.
		number of tuples generated will be multiple of the
		scaling factor. For example, -s 100 will imply 10M
		(10,000,000) tuples in the accounts table.
		default is 1.  NOTE: scaling factor should be at least
		as large as the largest number of clients you intend
		to test; else you'll mostly be measuring update contention.
		Regular (not initializing) runs using one of the
		built-in tests will detect scale based on the number of
		branches in the database.  For custom (-f) runs it can
		be manually specified with this parameter.

	-D varname=value
		Define a variable. It can be refered to by a script
		provided by using -f option. Multiple -D options are allowed.

	-U login
		Specify db user's login name if it is different from
		the Unix login name.

	-P password
		Specify the db password. CAUTION: using this option
		might be a security hole since ps command will
		show the password. Use this for TESTING PURPOSE ONLY.

	-n
		No vacuuming and cleaning the history table prior to the
		test is performed.

	-v
		Do vacuuming before testing. This will take some time.
		With neither -n nor -v, pgbench will vacuum tellers and
		branches tables only.

	-S
		Perform select only transactions instead of TPC-B.

	-N	Do not update "branches" and "tellers". This will
	        avoid heavy update contention on branches and tellers,
	        while it will not make pgbench supporting TPC-B like
	        transactions.

	-f filename
		Read transaction script from file. Detailed
		explanation will appear later.

	-C
		Establish connection for each transaction, rather than
		doing it just once at beginning of pgbench in the normal
		mode. This is useful to measure the connection overhead.
	
	-l
		Write the time taken by each transaction to a logfile,
		with the name "pgbench_log.xxx", where xxx is the PID
		of the pgbench process. The format of the log is:

			client_id transaction_no time file_no time-epoch time-us

		where time is measured in microseconds, , the file_no is
		which test file was used (useful when multiple were
		specified with -f), and time-epoch/time-us are a
		UNIX epoch format timestamp followed by an offset
		in microseconds (suitable for creating a ISO 8601
		timestamp with a fraction of a second) of when
		the transaction completed.

		Here are example outputs:

		0 199 2241 0 1175850568 995598
		0 200 2465 0 1175850568 998079
		0 201 2513 0 1175850569 608
		0 202 2038 0 1175850569 2663

	-F fillfactor

		Create tables(accounts, tellers and branches) with the given
		fillfactor. Default is 100.  This should be used with -i
		(initialize) option.
		
	-d
		debug option.


o What is the "transaction" actually performed in pgbench?

  (1) begin;

  (2) update accounts set abalance = abalance + :delta where aid = :aid;

  (3) select abalance from accounts where aid = :aid;

  (4) update tellers set tbalance = tbalance + :delta where tid = :tid;

  (5) update branches set bbalance = bbalance + :delta where bid = :bid;

  (6) insert into history(tid,bid,aid,delta) values(:tid,:bid,:aid,:delta);

  (7) end;

If you specify -N, (4) and (5) aren't included in the transaction.

o -f option

  This supports for reading transaction script from a specified
  file. This file should include SQL commands in each line. SQL
  command consists of multiple lines are not supported. Empty lines
  and lines begging with "--" will be ignored.

  Multiple -f options are allowed. In this case each transaction is
  assigned randomly chosen script.

  SQL commands can include "meta command" which begins with "\" (back
  slash). A meta command takes some arguments separted by white
  spaces. Currently following meta command is supported:

  \set name operand1 [ operator operand2 ]
        set the calculated value using "operand1" "operator"
        "operand2" to variable "name". If "operator" and "operand2"
        are omitted, the value of operand1 is set to variable "name".

  example:

  \set ntellers 10 * :scale

  \setrandom name min max

	assign random integer to name between min and max

  example:

  \setrandom aid 1 100000

  variables can be reffered to in SQL comands by adding ":" in front
  of the varible name.

  example:

  SELECT abalance FROM accounts WHERE aid = :aid

  Variables can also be defined by using -D option.

  \sleep num [us|ms|s]

	causes script execution to sleep for the specified duration of
	microseconds (us), milliseconds (ms) or the default seconds (s).

  example:

  \setrandom millisec 1000 2500
  \sleep :millisec ms

  Example, TPC-B like benchmark can be defined as follows(scaling
  factor = 1):

\set nbranches :scale
\set ntellers 10 * :scale
\set naccounts 100000 * :scale
\setrandom aid 1 :naccounts
\setrandom bid 1 :nbranches
\setrandom tid 1 :ntellers
\setrandom delta 1 10000
BEGIN
UPDATE accounts SET abalance = abalance + :delta WHERE aid = :aid
SELECT abalance FROM accounts WHERE aid = :aid
UPDATE tellers SET tbalance = tbalance + :delta WHERE tid = :tid
UPDATE branches SET bbalance = bbalance + :delta WHERE bid = :bid
INSERT INTO history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, 'now')
END

If you want to automatically set the scaling factor from the number of
tuples in branches table, use -s option and shell command like this:

pgbench -s $(psql -At -c "SELECT count(*) FROM branches") -f tpc_b.sql

Notice that -f option does not execute vacuum and clearing history
table before starting benchmark.

o License?

Basically it is same as BSD license. See pgbench.c for more details.

o History before contributed to PostgreSQL

2000/1/15 pgbench-1.2 contributed to PostgreSQL
	* Add -v option

1999/09/29 pgbench-1.1 released
	* Apply cygwin patches contributed by Yutaka Tanida
	* More robust when backends die
	* Add -S option (select only)

1999/09/04 pgbench-1.0 released
@


1.20
log
@Changed new \usleep command into \sleep with an optional time unit
argument to specify us, ms or s. As per suggestion by Peter E.

Jan
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/contrib/pgbench/README.pgbench,v 1.19 2007/07/06 13:36:55 wieck Exp $
@


1.19
log
@Added a new scripting meta command

    \usleep [milliseconds|:variable]

which can be used in -f scripts to insert a thinking time between
other commands.

Jan
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/contrib/pgbench/README.pgbench,v 1.18 2007/04/08 01:15:07 ishii Exp $
d234 1
a234 1
  \usleep usec
d236 2
a237 2
	causes script execution to sleep for the specified duration in
	microseconds.
d241 2
a242 2
  \setrandom usec 1000000 3000000
  \usleep :usec
@


1.18
log
@Add -F option to set fillfactor for tellers, accounts and branches.
Patch contributed by Pavan Deolasee. Along with Japanese doc
modification by Tatsuo Ishii.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/contrib/pgbench/README.pgbench,v 1.17 2007/04/06 09:16:15 ishii Exp $
d234 10
@


1.17
log
@Enhance pgbench -l option to add timestamp. Patch contributed by Greg
Smith. Along with Japanese doc updation by Tasuo Ishii.

> This patch changes the way pgbench outputs its latency log files so that
> every transaction gets a timestamp and notes which transaction type was
> executed.  It's a one-line change that just dumps some additional
> information that was already sitting in that area of code. I also made a
> couple of documentation corrections and clarifications on some of the more
> confusing features of pgbench.
>
> It's straightforward to parse log files in this format to analyze what
> happened during the test at a higher level than was possible with the
> original format.  You can find some rough sample code to convert this
> latency format into CVS files and then into graphs at
> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll
> be expanding on once I get all my little patches sent in here.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/contrib/pgbench/README.pgbench,v 1.16 2007/04/06 08:49:44 ishii Exp $
d60 3
a62 2
	You can increase the number of tuples by using -s option. See
	below.
d166 6
@


1.16
log
@Various pgbench enhancements. Patch contributed by ITAGAKI Takahiro.

Also tweak README.pgbench/README.pgbench_jis:
  Remove history after pgbench was added to PostgreSQL contrib module.
  Those info was not only redundant since it has already been in CVS
  log, but also incomplete.
--------------------------------------------------------------------------
The attached is a patch to optimize contrib/pgbench using new 8.3 features.

- Use DROP IF EXISTS to suppress errors for initial loadings.
- Use a combination of TRUNCATE and COPY to reduce WAL on creating
  the accounts table.

Also, there are some cosmetic changes.

- Change the output of -v option from "starting full vacuum..."
  to "starting vacuum accounts..." in reflection of the fact.
- Shape duplicated error checks into executeStatement().


There is a big performance win in "COPY with no WAL" feature.
Thanks for the efforts!
--------------------------------------------------------------------------
@
text
@d1 1
a1 1
$PostgreSQL$
d99 4
d105 2
a106 2
		Define a variable. It can be refereed to by a script
		provided by using -f option. Multile -D options are allowed.
d148 1
a148 1
			client_id transaction_no time
d150 14
a163 1
		where time is measured in microseconds.
d185 2
@


1.15
log
@pgbench: More fix with handling default scaling factor in the default
scenarios. With multiple clinets, only the first client got the right
scaling factor and this gave a illusion of better performance in case
of the scaling factor greater than 1.
@
text
@d1 3
a3 1
pgbench README		2006/10/21 Tatsuo Ishii
d238 1
a238 48
o History

2006/10/21
	* more fix with handling default scaling factor in the default
          scenarios

2006/09/14
	* change "tps" to "scale" to avoid confusion

	* fix bug with handling default scaling factor in the default
          scenarios

2006/07/26
	* New features contributed by Tomoaki Sato.

	* predefined variable "tps"
	    The value of variable tps is taken from the scaling factor
	    specified by -s option.
        * -D option
	   Variable values can be defined by -D option.
	* \set command now allows arithmetic calculations.

2005/09/29
	* add -f option. contributed by Tomoaki Sato.

[updation records were missing]

2003/11/26
	* create indexes after data insertion to reduce time.
	  patch from Yutaka Tanida.

2003/06/10
	* fix uninitialized memory bug
	* add support for PGHOST, PGPORT, PGUSER environment variables

2002/07/20
	* patch contributed by Neil Conway.
	* code/document clean up and add -l option.

2002/02/24
	* do not CHECKPOINT anymore while initializing benchmark
	* database. Add -N option.

2001/10/24
	* "time"->"mtime"

2001/09/09
	* Add -U, -P, -C options
@


1.14
log
@Change "tps" to "scale" to avoid confusion

Fix bug with handling default scaling factor in the default
scenarios
@
text
@d1 1
a1 1
pgbench README		2006/07/26 Tatsuo Ishii
d238 4
@


1.13
log
@New features contributed by Tomoaki Sato.

- predefined variable "tps"
  The value of variable tps is taken from the scaling factor
  specified by -s option.

- -D option
  Variable values can be defined by -D option.

- \set command now allows arithmetic calculations.
@
text
@d187 1
a187 1
  \set ntellers 10 * :tps
d209 3
a211 3
\set nbranches :tps
\set ntellers 10 * :tps
\set naccounts 100000 * :tps
d238 6
@


1.12
log
@Allow multiple -f options.
Make pgbench "script driven" to eliminate hard coded transaction
scenario. (Tatsuo Ishii)
@
text
@d1 1
a1 1
pgbench README		2005/10/04 Tatsuo Ishii
d5 7
a11 7
  pgbench is a simple program to run a benchmark test sort of
  "TPC-B". pgbench is a client application of PostgreSQL and runs
  with PostgreSQL only. It performs lots of small and simple
  transactions including select/update/insert operations then
  calculates number of transactions successfully completed within a
  second (transactions per second, tps). Targeting data includes a
  table with at least 100k tuples.
d42 1
a42 1
  (1) Initialize database by:
d98 4
d180 9
d204 3
a206 1
  For example, TPC-B like benchmark can be defined as follows(scaling
d209 6
a214 3
\setrandom aid 1 100000
\setrandom bid 1 1
\setrandom tid 1 10
d224 8
d238 10
@


1.11
log
@Add -f option which enables to read SQL commands from a file.
Patches Contributed by Tomoaki Sato.
@
text
@d1 1
a1 1
pgbench README		2005/09/29 Tatsuo Ishii
d169 3
@


1.10
log
@Patches from Yutaka Tanida. Create primary key indexes after data
insertion to reduce initialization time.
@
text
@d1 1
a1 1
pgbench README		2003/11/26 Tatsuo Ishii (t-ishii@@sra.co.jp)
d37 2
a38 10
 (1) Configure and build the standard Postgres distribution.

     You can get away with just running configure at the top level
     and doing "make all" in src/interfaces/libpq.

 (2) Run make in this directory.

     You will see an executable file "pgbench".  You can run it here,
     or install it with the standard Postgres programs by doing
     "make install".
d119 9
d162 41
d209 5
@


1.9
log
@Fix uninitialized memory bug
Add support for PGHOST, PGPORT, PGUSER environment variables
@
text
@d1 1
a1 1
pgbench README		2002/07/20 Tatsuo Ishii (t-ishii@@sra.co.jp)
d166 4
@


1.9.4.1
log
@Patches from Yutaka Tanida. Create primary key indexes after data
insertion to reduce initialization time.
@
text
@d1 1
a1 1
pgbench README		2003/11/26 Tatsuo Ishii (t-ishii@@sra.co.jp)
a165 4

2003/11/26
	* create indexes after data insertion to reduce time.
	  patch from Yutaka Tanida.
@


1.8
log
@Add note that scaling factor should be >= # of clients.
@
text
@d167 4
@


1.7
log
@Apply patches from Neil Conway.

> Hi Tatsuo,
>
> I've attached a patch for the version of pgbench in CVS. It includes the
> following changes:
>
>     - fix some spelling mistakes, indentation stuff, etc.
>
>     - minor code cleanup -- (void) args instead of (), etc.
>
>     - allocate the state array dynamically, so that it is only as
>     large as needed. This reduces the memory consumption of pgbench
>     slightly, and makes a larger MAXCLIENTS setting possible
>
>     - (the only controversial change) add an option "-l" to log
>     transaction latencies to a file. The "transaction latency"
>     is the time between when the BEGIN is issued and the transaction
>     commits. This is written to a file, along with the client #
>     and the transaction #. The data in the file can then be used
>     for things like:
>
>         - consistency analysis: is the TPS the same through the
>         entire run of pgbench, or does it change?
>
>         - more detailed stats: what is the average latency, worse-case
>         latency, best-case latency?
>
>         - graphs: feed the data to gnuplot, graph latency versus. time
>
>         - etc.
>
>     I was going to store this data in memory and write it to disk
>     at the end of the pgbench run, but that isn't feasible because
>     the data can be very large: for example, ~70MB if benchmarking
>     128 clients doing 100,000 transactions each.
>
> Cheers,
>
> Neil
@
text
@d102 3
a104 1
		default is 1.
@


1.6
log
@Update docs about new -N option
@
text
@d1 1
a1 1
pgbench README		2001/10/24 Tatsuo Ishii (t-ishii@@sra.co.jp)
d104 1
a104 1
        -U login
d114 1
a114 1
		No vacuuming and cleaning the history table prior the
d125 1
a125 1
        -C
d127 11
a137 2
		doing it just once at begining of pgbench in the normal
		mode. This is usefull to measure the connection overhead.
d164 8
@


1.5
log
@Add -N option which disables updation of branches and tellers tables.
So there would be less contention with -N, that might be more realistic
test.
@
text
@d1 1
a1 1
pgbench README		2002/02/24 Tatsuo Ishii (t-ishii@@sra.co.jp)
a124 3
	-N
		Skip updation of "branches" and "tellers" table. This
		would result in lower contention of updates.
a154 4

2002/02/24
	* disable CHECKPOINT
	* add -N option
@


1.4
log
@"time" is now a reserved keyword(changed to "mtime").
@
text
@d1 1
a1 1
pgbench README		2001/10/24 Tatsuo Ishii (t-ishii@@sra.co.jp)
d125 3
d158 4
@


1.3
log
@Add -U, -P, -C options. See README.pgbench for more details.
@
text
@d1 1
a1 1
pgbench 1.3 README		2001/09/09 Tatsuo Ishii (t-ishii@@sra.co.jp)
d156 3
d170 1
a170 1
1999/09/04 pgbench-1.0 released@


1.2
log
@Update README's install instructions to agree with current reality.
@
text
@d1 1
a1 1
pgbench 1.2 README		2000/1/15 Tatsuo Ishii (t-ishii@@sra.co.jp)
d104 9
d125 5
d155 3
@


1.1
log
@Add missing /contrib files
@
text
@d37 1
a37 1
 (1) Edit the first line in Makefile
d39 2
a40 1
	POSTGRESHOME = /usr/local/pgsql
d42 1
a42 1
     so that it points to the directory where PostgreSQL installed.
d44 3
a46 3
 (2) Run configure

 (3) Run make. You will see an executable file "pgbench" there.
d56 1
a56 1
      destroyed. Be very carefully if you have tables having same
d89 1
a89 1
		5432.
d110 1
a110 1
		Without both -n and -v pgbench will vacuum tellers and
@
