提早很关键
典型的客户端/主机往复的网络提早，交流机网络范畴从 0.01 毫秒（本机）到 ~0.5 毫秒、WiFi 网络 5 毫秒、ADSL 网络 20 毫秒、洲际路由网络 300 毫秒，甚至更高，例如卫星和 WWAN 链接。
一个个别的SELECT或许须要 0.1 毫秒左右，能力在主机端口头。一个个别的INSERT或许须要 0.5 毫秒。
每次运行程序运转查问时，它都必定等候主机照应成功/失败，或许还有结果集、查问元数据等。这会造成至少一次性网络往复提早。
当您在处置小型的繁难查问时，假设您的数据库与运行程序不在同一主机上，则相关于查问的口头期间，网络提早或许会很长。
许多运行程序，尤其是 ORM，很容易运转许多十分繁难的查问。例如，假设你的 Hibernate 运行程序正在失掉一个实体，它会提早失掉@OneToMany相关关联到的 1000 个子项，那么由于这样 n+1 次 select 的疑问，假设不是更多的话，它或许会口头 1001 次查问。这象征着它或许要破费 1000 倍于您的网络往复提早来等候。你可以用left join fetch来防止这种状况，然而，您在衔接中传输父实体 1000 次，并且必定对其启动反双数据删除。
雷同，假设你从 ORM 填充数据库，你或许正在口头数十万个个别INSERT，并在每一个恳求之后等候主机确认它没疑问。
尝试关注查问口头期间并尝试优化它很容易，然而关于个别的INSERT INTO ...VALUES ...，您可以做的并不多。删除一些索引和解放，确保它在一个事务中批处置口头，而后你就差不多成功了。
那解脱一切网络等候怎样样？即使在局域网上，它们也开局累积数千个查问。
防止提早的一种方法是经常使用COPY。要经常使用 PostgreSQL 的 COPY 个性，您的运行程序或驱动程序必定生成一组相似 CSV 的行，并将它们以延续的顺序流式传输到主机。或许，可以要求主机向您的运行程序发送相似 CSV 的流。
无论哪种方式，运行程序都不能将 COPY 与其余查问交织，并且必定将 copy-insert 间接加载到目的表中。一种经常出现的方法是先COPY进入一个暂时表，而后从那里口头INSERT INTO ... SELECT ...，UPDATE ... FROM ....，DELETE FROM ... USING...等操作，以经常使用复制的数据在单个操作中修正主表。
假设您间接编写自己的 SQL，这很繁难，但许多运行程序框架和 ORM 不允许它，而且它只能间接交流繁难的INSERT。您的运行程序、框架或客户端驱动程序必定针对COPY所需的不凡示意做好转换，查找任何其自身所需的类型元数据等。
（允许COPY的有名驱动程序包含 libpq、PgJDBC、psycopg2 和 Pg gem，但不必定是构建在它们之上的框架和 ORM。）
PL/pgSQL 函数
PL/pgSQL 函数是一组预先创立并存储在数据库主机上的 SQL 语句，它具备一个指定的称号。频繁或复杂的操作可经过提早编写 SQL 语句来存储。当未来须要数据库提供相反的服务时，只有再次口头存储的函数即可。
复杂的业务逻辑须要多个 SQL 语句。当客户端和主机之间有很多操作时，会发生少量的网络传输。假设将这些操作放在存储函数中，客户端和主机之间的网络传输将缩小，从而缩小网络负载。
PgJDBC – 批处置形式
PostgreSQL 的 JDBC 驱动程序为此疑问提供了处置打算。它依赖于 PostgreSQL 主机自 8.4 以来的允许，以及JDBC API 的批处感性能，将一批查问发送到主机，而后只等候一次性以确认整个批处置运转反常。
这只是通常上的。实践上，一些成功的应战限度了这一点，因此批处置最多只能以几百个查问的块成功。假设驱动程序可以提早计算出结果的大小，则驱动程序也只能运转以批处置块方式前往结果行的查问。虽然存在这些限度，然而关于口头批量数据加载到远程数据库实例等义务的运行程序，经常使用Statement.executeBatch()可以为其提供渺小的性能优化。
由于它是规范 API，所以它可以被跨多个数据库引擎上班的运行程序经常使用。例如，Hibernate 可以经常使用JDBC 批处置，虽然自动状况下它不这样做。
遗憾的是，无法智能为现有运行程序启用批处置。运行程序必定经常使用略有不同的接口，它们先发送一系列查问，而后才征询结果。
性能
像 RDS Postgres 这样的托管数据库服务，会是一个很好的例子，来说明这种性能是十分有用的。特意是，从咱们自己的网络访问他们，确实显示了提早带来的侵害有多大。
在 ~320 毫秒网络提早时：
•500 个 INSERT，无批处置：167 秒
•500 个带批处置的 INSERT：1.2 秒
… 这快了 120 倍以上。
您通常不会跨运行主机和数据库之间的洲际网络，来运转您的运行，但这有助于突出提早的影响。即使在本机的 unix 套接字上，也能看到 10000 次拔出的性能提高了 50% 以上。
COPY 速度最快
实践客户依然应该倾向COPY。以下是团体上班电脑上的一些结果：
inserting 1000000 rows batched, unbatched and with COPYbatch insert elapsed:23.715315ssequential insert elapsed: 36.150162sCOPY elapsed:1.743593sDone.批处置上班即使在本地 unix 套接字衔接上，也能提供令人惊讶的渺小性能优化。但COPY将两个独自的拔出方法都远远抛在了前面。
尽量经常使用COPY吧。