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

pgbench -i [ other-options ] dbname

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

At the default “scale factor” of 1, the tables initially contain this many rows:

table                   # of rows
---------------------------------
pgbench_branches        1
pgbench_tellers         10
pgbench_accounts        100000
pgbench_history         0

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

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

pgbench [ options ] dbname

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

第 F.26.2 节给出数据库初始化期间使用的选项，第 F.26.3 节给出运行基准测试期间使用的选项，而第 F.26.4 节给出两种情况下都有用的选项。

pgbench 接受以下命令行初始化参数：

pgbench 接受以下命令行基准测试参数：

pgbench 接受以下通用命令行参数：

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

如果指定-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 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;

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

使用 -l 选项时，pgbench 会把每个事务所耗时间写入日志文件。日志文件名为 pgbench_log.nnn，其中 nnn 是 pgbench 进程的 PID。如果 -j 选项为 2 或更高（创建多个工作线程），每个线程都会有自己的日志文件。第一个工作线程的日志文件名与标准单工作线程情形相同。其余工作线程的额外日志文件名为 pgbench_log.nnn.mmm，其中 mmm 是从 1 开始的各工作线程顺序编号。

日志格式如下：

client_id transaction_no time file_no time_epoch time_us

其中，time 是事务经过的总时间，单位为微秒，file_no 标识使用的脚本文件（在通过 -f 指定多个脚本时很有用），而 time_epoch/time_us 分别是 Unix 纪元格式的时间戳和以微秒计的偏移量（适合用来生成带小数秒的 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

使用-r选项时，pgbench会收集每个客户端执行的每条语句所经过的事务时间。基准测试完成后，它会报告这些值的平均值，称为每条语句的延迟。

对于默认脚本，输出与下面类似：

starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 618.764555 (including connections establishing)
tps = 622.977698 (excluding connections establishing)
statement latencies in milliseconds:
        0.004386        \set nbranches 1 * :scale
        0.001343        \set ntellers 10 * :scale
        0.001212        \set naccounts 100000 * :scale
        0.001310        \setrandom aid 1 :naccounts
        0.001073        \setrandom bid 1 :nbranches
        0.001005        \setrandom tid 1 :ntellers
        0.001078        \setrandom delta -5000 5000
        0.326152        BEGIN;
        0.603376        UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
        0.454643        SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
        5.528491        UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
        7.335435        UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
        0.371851        INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        1.212976        END;

如果指定了多个脚本文件，则会分别为每个脚本文件报告平均值。

注意，为逐语句延迟计算收集额外的计时信息会带来一定开销。这会拖慢平均执行速度，并降低计算出的 TPS。减速幅度在很大程度上取决于平台和硬件。比较启用和未启用延迟报告时的平均 TPS 值，是判断这一计时开销是否显著的好方法。

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

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

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

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

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