针对大量插入和bytea更新优化PostgreSQL

我们拥有（软件​​）：

• 具有基本配置的PostrgeSQL 9.3（中没有更改postgresql.conf）
• Windows 7 64位

硬件：

• 英特尔酷睿i7-3770 3.9 GHz
• 32 Gb RAM
• WDC WD10EZRX-00L4HBAta驱动器（1000Gb，SATA III）

因此，我们必须加载到数据库aprox中。100.000.000行（带bytea列），以及更简单的500.000.000行（无LOB）。varchar在第一个表上有2个索引（长度为13、19），varchar在第二个表上有2 个索引（长度为18，10）。每个表还具有用于ID生成的序列。

到目前为止，这些操作是使用8个连接进行的，并具有5​​0个JDBC批处理大小。下图演示了系统负载：postgresql进程的负载为零。加载24小时后，我们仅加载了1000万行，这是非常缓慢的结果。

我们正在寻求有关调整PostrgreSQL配置的帮助，以实现以下目的：

1）为了超快地加载此数据量，这是一次操作，因此可以是临时配置

2）对于生产模式，通过它们的索引对这2个表进行适量的SELECT，而无需联接和排序。

对于insert性能，见加快插在PostgreSQL的性能和批量插入PostgreSQL中。

您在浪费JDBC批处理的时间insert。PgJDBC对insert批处理没有任何帮助，它仅运行每个语句。<-在新的PgJDBC版本中不再如此，该版本现在可以批处理准备好的语句以显着减少往返时间。但最好还是：

使用COPY代替；请参阅PgJDBC批处理副本和CopyManager。至于并发加载程序的数量：如果操作受磁盘I / O限制，则每个磁盘目标为一对。八个可能是您最想要的。

对于您的“生产模式”，我建议加载一个数据样本，设置您希望运行的查询，并explain analyze用于调查性能。仅出于测试目的，请使用enable_参数探索不同的计划选择。设置查询规划成本参数（random_page_cost，seq_page_cost，effective_cache_size等）适当地为您的系统，并确保shared_buffers正确设置。使用auto_explain模块，log_min_duration_statement设置，pg_stat_statements扩展名等添加模拟的生产工作负载时，继续监视。

有关详细信息，请参见PostgreSQL用户手册。如果您在explain analyze查询执行详细信息等方面遇到更具体的问题，建议您回到此处。