1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00

Change pgbench to use the table names pgbench_accounts, pgbench_branches,

pgbench_history, and pgbench_tellers, rather than just accounts, branches,
history, and tellers.  This is to prevent accidental conflicts with real
application tables, as has been reported to happen at least once.  Also
remove the automatic "SET search_path = public" that it did at startup,
as this seems to restrict testing flexibility without actually buying much.
Per proposal by Joshua Drake and ensuing discussion.

Joshua Drake and Tom Lane
This commit is contained in:
Tom Lane
2009-05-07 22:01:18 +00:00
parent fdd48b1852
commit 48caf91b66
2 changed files with 94 additions and 91 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.7 2008/09/11 23:52:48 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.8 2009/05/07 22:01:18 tgl Exp $ -->
<sect1 id="pgbench">
<title>pgbench</title>
@ -25,6 +25,7 @@
<programlisting>
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
@ -32,7 +33,7 @@ tps = 85.184871 (including connections establishing)
tps = 85.296346 (excluding connections establishing)
</programlisting>
The first four lines just report some of the most important parameter
The first five lines report some of the most important parameter
settings. The next line reports the number of transactions completed
and intended (the latter being just the product of number of clients
and number of transactions per client); these will be equal unless the run
@ -63,9 +64,10 @@ pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbn
<caution>
<para>
<literal>pgbench -i</> creates four tables <structname>accounts</>,
<structname>branches</>, <structname>history</>, and
<structname>tellers</>, destroying any existing tables of these names.
<literal>pgbench -i</> creates four tables <structname>pgbench_accounts</>,
<structname>pgbench_branches</>, <structname>pgbench_history</>, and
<structname>pgbench_tellers</>,
destroying any existing tables of these names.
Be very careful to use another database if you have tables having these
names!
</para>
@ -76,12 +78,12 @@ pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbn
contain this many rows:
</para>
<programlisting>
table # of rows
-------------------------
branches 1
tellers 10
accounts 100000
history 0
table # of rows
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0
</programlisting>
<para>
You can (and, for most purposes, probably should) increase the number
@ -134,15 +136,16 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<entry><literal>-s</literal> <replaceable>scale_factor</></entry>
<entry>
Multiply the number of rows generated by the scale factor.
For example, <literal>-s 100</> will imply 10,000,000 rows
in the <structname>accounts</> table. Default is 1.
For example, <literal>-s 100</> will create 10,000,000 rows
in the <structname>pgbench_accounts</> table. Default is 1.
</entry>
</row>
<row>
<entry><literal>-F</literal> <replaceable>fillfactor</></entry>
<entry>
Create the <structname>accounts</>, <structname>tellers</> and
<structname>branches</> tables with the given fillfactor.
Create the <structname>pgbench_accounts</>,
<structname>pgbench_tellers</> and
<structname>pgbench_branches</> tables with the given fillfactor.
Default is 100.
</entry>
</row>
@ -177,14 +180,15 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<row>
<entry><literal>-T</literal> <replaceable>seconds</></entry>
<entry>
Duration of benchmark test in seconds. <literal>-t</literal> and
Run the test for this many seconds, rather than a fixed number of
transactions per client. <literal>-t</literal> and
<literal>-T</literal> are mutually exclusive.
</entry>
</row>
<row>
<entry><literal>-M</literal> <replaceable>querymode</></entry>
<entry>
Protocol to use for submitting queries for the server:
Protocol to use for submitting queries to the server:
<itemizedlist>
<listitem>
<para><literal>simple</>: use simple query protocol.</para>
@ -203,7 +207,8 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<row>
<entry><literal>-N</literal></entry>
<entry>
Do not update <structname>tellers</> and <structname>branches</>.
Do not update <structname>pgbench_tellers</> and
<structname>pgbench_branches</>.
This will avoid update contention on these tables, but
it makes the test case even less like TPC-B.
</entry>
@ -226,21 +231,21 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<row>
<entry><literal>-n</literal></entry>
<entry>
No vacuuming is performed before running the test.
Perform no vacuuming before running the test.
This option is <emphasis>necessary</>
if you are running a custom test scenario that does not include
the standard tables <structname>accounts</>,
<structname>branches</>, <structname>history</>, and
<structname>tellers</>.
the standard tables <structname>pgbench_accounts</>,
<structname>pgbench_branches</>, <structname>pgbench_history</>, and
<structname>pgbench_tellers</>.
</entry>
</row>
<row>
<entry><literal>-v</literal></entry>
<entry>
Vacuum all four standard tables before running the test.
With neither <literal>-n</> nor <literal>-v</>, pgbench will vacuum
<structname>tellers</> and <structname>branches</> tables, and
will remove all entries in <structname>history</>.
With neither <literal>-n</> nor <literal>-v</>, pgbench will vacuum the
<structname>pgbench_tellers</> and <structname>pgbench_branches</>
tables, and will truncate <structname>pgbench_history</>.
</entry>
</row>
<row>
@ -271,7 +276,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
Report the specified scale factor in <application>pgbench</>'s
output. With the built-in tests, this is not necessary; the
correct scale factor will be detected by counting the number of
rows in the <structname>branches</> table. However, when testing
rows in the <structname>pgbench_branches</> table. However, when testing
custom benchmarks (<literal>-f</> option), the scale factor
will be reported as 1 unless this option is used.
</entry>
@ -323,11 +328,11 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<orderedlist>
<listitem><para><literal>BEGIN;</literal></para></listitem>
<listitem><para><literal>UPDATE accounts SET abalance = abalance + :delta WHERE aid = :aid;</literal></para></listitem>
<listitem><para><literal>SELECT abalance FROM accounts WHERE aid = :aid;</literal></para></listitem>
<listitem><para><literal>UPDATE tellers SET tbalance = tbalance + :delta WHERE tid = :tid;</literal></para></listitem>
<listitem><para><literal>UPDATE branches SET bbalance = bbalance + :delta WHERE bid = :bid;</literal></para></listitem>
<listitem><para><literal>INSERT INTO history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);</literal></para></listitem>
<listitem><para><literal>UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;</literal></para></listitem>
<listitem><para><literal>SELECT abalance FROM pgbench_accounts WHERE aid = :aid;</literal></para></listitem>
<listitem><para><literal>UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;</literal></para></listitem>
<listitem><para><literal>UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;</literal></para></listitem>
<listitem><para><literal>INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);</literal></para></listitem>
<listitem><para><literal>END;</literal></para></listitem>
</orderedlist>
@ -410,7 +415,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<listitem>
<para>
Sets variable <replaceable>varname</> to a random integer value
between the limits <replaceable>min</> and <replaceable>max</>.
between the limits <replaceable>min</> and <replaceable>max</> inclusive.
Each limit can be either an integer constant or a
<literal>:</><replaceable>variablename</> reference to a variable
having an integer value.
@ -463,11 +468,11 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
\setrandom tid 1 :ntellers
\setrandom delta -5000 5000
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, CURRENT_TIMESTAMP);
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
</programlisting>
@ -537,7 +542,7 @@ END;
(<literal>-s</>) should be at least as large as the largest number of
clients you intend to test (<literal>-c</>); else you'll mostly be
measuring update contention. There are only <literal>-s</> rows in
the <structname>branches</> table, and every transaction wants to
the <structname>pgbench_branches</> table, and every transaction wants to
update one of them, so <literal>-c</> values in excess of <literal>-s</>
will undoubtedly result in lots of transactions blocked waiting for
other transactions.