（我将尝试简要介绍我正在尝试实现的目标，然后描述我面临的问题）
目标
好的，所以我正在对 PostgreSQL 中的语句执行时间进行基本基准测试（通过 JDBC）。我目前正在测试的案例如下：
实验 #1：将 5000 个订单插入到订单表中。存储每个 INSERT 的绝对执行时间并计算平均值。SQL 类似于：
INSERT INTO Order(order_ID, order_state_R_ID, customer_ID, submission_time,
acceptance_time, completion_time, additional_info) VALUES (?, ?, ?, ?, ?, ?, ?);
实验 #2：从订单表中选择一个订单 5000 次。存储每个 SELECT 的绝对执行时间并计算平均值。因此，基本上之前实验中插入的每一行都会被逐一读取，以大致了解需要多长时间。对应的SQL：
SELECT * FROM Order WHERE order_ID = ?;
实验#3：删除在实验#1 中插入的每个订单（同样，一个接一个）。存储每个 DELETE 的绝对执行时间并计算平均值。
DELETE FROM Order WHERE order_ID = ?;
问题
起初，我在 Windows 7 上运行这些实验（默认安装 PostgreSQL 9.2）。我得到的平均值是：（#1：1.5 ms），（#2：0.4 ms），（#3：1.9 ms）。
现在，为了更好地了解与另一个专门在 Linux 上运行的 DBMS 相比的速度，我在 Fedora 17 中重建了整个环境（同一台 PC，不同的逻辑分区）并再次运行测试。我的问题是，由于某种奇怪的原因，结果现在更像 (#1: 15 ms), (#2: 0.2 ms), (#3: 15 ms)。这意味着与 Windows 相比，SELECT 稍快，但 INSERT 和 DELETE 慢得多。在这两种情况下，数据库是相同的。此外，运行 ANALYZE 或 VACUUM FULL 似乎没有任何区别。
我确实意识到这里有很多开放式的结局。但是，我想知道是否有人遇到过类似的情况或对瓶颈可能在哪里有任何提示？
澄清一下：我的目标不是探究 PostgreSQL 的任何事务吞吐量能力，而是找出上述语句的绝对执行时间。因此，每个实验中的每个语句都使用单个数据库连接在一个线程上串行执行。