默认的类 TPC-B 事务测试要求预先建立特定的表。应使用 -i（初始化）选项调用 pgbench 来创建并填充这些表。（测试 自定义脚本时不需要这一步，但需要自行完成测试所需的准备工作。） 初始化命令如下：

pgbench -i [ other-options ] dbname

其中 dbname 是要在其中进行测试的已创建 数据库的名称。（可能还需要 -h、 -p 和/或 -U 选项来指定如何连接数据库服务器。）

在默认的 1 倍“缩放因子”下，各表最初包含的行数如下：

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

你可以（而且对于大多数用途来说，也许应该）使用 -s（缩放因子）选项增加行数。此时还可以使用 -F（填充因子）选项。

完成必要的设置之后，就可以用不带 -i 的命令运行基准测试，即

pgbench [ options ] dbname

几乎在所有情况下，都需要一些选项才能做出有意义的测试。最重要 的选项是 -c（客户端数量）、 -t（事务数量）和 -f（指定自定义脚本文件）。 完整列表见下文。

表 F.14 给出数据库初始化期间使用的 选项，表 F.15 给出运行基准测试期间 使用的选项，而 表 F.16 给出两种情况下都有用的 选项。

默认的事务脚本在每个事务中发出七条命令：

如果指定 -N，事务中不包括第 4 步和第 5 步。 如果指定 -S，则只发出 SELECT。

pgbench 支持运行自定义基准场景，方法 是用从文件读取的事务脚本（ -f 选项）替换（前文所述的）默认事务脚本。 在这种情况下，一次“事务”算作脚本文件的一次执行。 甚至可以指定多个脚本（多个 -f 选项），此时每次客户端会话开始新事务时， 都会随机选择其中一个脚本。

脚本文件的格式是每行一条 SQL 命令；不支持跨多行的 SQL 命令。空行以及以--开头的行会被忽略。脚本文件的行还可以是“元命令”，它们由pgbench自身解释，详见下文。

脚本文件有一个简单的变量替换设施。变量可以通过命令行 -D 选项（前文已说明）或下文说明的元命令来 设置。除了由 -D 命令行选项预设的变量之外，变量 scale 会被预设为当前缩放因子。变量一经设置， 就可以通过写成 :variablename 把它的值 插入 SQL 命令中。运行多个客户端会话时，每个会话都有自己的一组 变量。

脚本文件中的元命令以反斜线（\）开头。元命令的参数以空白分隔。支持的元命令如下：

作为一个示例，内置的类 TPC-B 事务的全部定义是：

\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 -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);
END;

该脚本允许事务的每次迭代都引用不同的随机选中行。（这个示例也说明了为什么每个客户端会话都必须拥有自己的变量 — 否则它们就无法彼此独立地访问不同的行。）

使用 -l 选项时，pgbench 会把每个事务所耗时间写入日志文件。日志文件名为 pgbench_log.nnn， 其中 nnn 是 pgbench 进程的 PID。日志的 格式为：

client_id transaction_no time file_no time_epoch time_us
   

其中 time 是以微秒计的事务耗时， file_no 标识使用的是哪个脚本文件 （在用 -f 指定多个脚本时有用），而 time_epoch/time_us 是 UNIX epoch 格式的时间戳和以微秒计的偏移量（适合用于构造 带小数秒的 ISO 8601 时间戳），表示事务完成的时间。

示例输出如下：

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

很容易用pgbench得出完全没有意义的数字。下面给出一些有助于获得有用结果的准则。

首先，绝不要相信任何只运行几秒钟的测试。 把 -t 设置得足够大，让运行至少持续几分钟，以平均掉噪声。 在某些情况下，可能需要数小时才能获得可重现的数字。最好把 测试多运行几次，看看你的数字是否可重现。

对于默认的类 TPC-B 测试场景，初始化缩放因子 （-s）至少应与你打算测试的最大客户端数 （-c）一样大；否则你测到的将主要是更新争用。 branches 表中只有 -s 行，而每个事务都要更新其中一行，因此 -c 值超过 -s 无疑会导致大量事务阻塞等待其他事务。

默认测试场景还会对表初始化后的时间长短非常敏感：表中死元组和无效空间的累积会改变结果。要理解这些结果，必须跟踪更新总数以及何时发生清理。如果启用了自动清理，它可能会给测得的性能带来不可预测的变化。

pgbench的一个局限是：在尝试测试大量客户端会话时，它自己也可能成为瓶颈。可以通过在与数据库服务器不同的机器上运行pgbench来缓解这一点，不过网络延迟必须足够低。甚至可以在多台客户端机器上同时运行多个pgbench实例，对同一台数据库服务器施压。