问邮政分拣

EN

为此，您可以对您的表进行CLUSTER：

CLUSTER all_emails USING all_emails_email_idx;
ANALYZE all_emails;

根据指定的索引对表中的行进行物理重新排序。因此，电子邮件地址是根据电子邮件地址排序的，然后查询--就像处理任何其他查询一样--将在有限数量的磁盘页面上找到请求子集中的所有行，因此I/O减少，以及任何排序(因为查询计划器识别表聚集在特定索引上)。ANALYZE命令在集群之后更新表统计信息，以帮助查询规划者做出最佳选择。

这实际上只适用于只读或不经常更新或插入新行的表，因为群集不被维护:这是一个一次性的过程。集群也是一个相当“昂贵”的过程，因为整个表是重写的，并且需要一个排他的表锁。您可以使用缩写形式CLUSTER all_emails的相同索引定期重新对表进行重新聚类。

没有什么比读取整个表的单次顺序扫描速度更快的了，至少在PostgreSQL 9.6之前是这样，在此之前，并行顺序扫描将被引入。

将表拆分为ctid (表中元组的物理位置)是很有诱惑力的，但是PostgreSQL并没有为不同于=的运营商优化ctid的访问

test=> EXPLAIN SELECT * FROM large WHERE ctid BETWEEN '(390, 0)' AND '(400,0)';
┌───────────────────────────────────────────────────────────────────┐
│                            QUERY PLAN                             │
├───────────────────────────────────────────────────────────────────┤
│ Seq Scan on large  (cost=0.00..1943.00 rows=500 width=8)          │
│   Filter: ((ctid >= '(390,0)'::tid) AND (ctid <= '(400,0)'::tid)) │
└───────────────────────────────────────────────────────────────────┘
(2 rows)

插入的情况也是如此:如果不能显示数字，我非常肯定，将一个进程INSERTing或COPYing放到一个表中不会比将数据加载到同一个表中的几个进程慢。

由于瓶颈似乎是处理原点的SELECT和目的地的INSERT之间的行，我建议如下：

1. 有一个执行单个SELECT * FROM all_emails的线程。
2. 创建多个可以并行执行昂贵处理的线程。
3. 第一个线程以循环方式将结果行分发给并行工作人员。
4. 还有一个线程收集并行工作人员的结果，并将它们组合到它执行的COPY tablename FROM STDIN语句的输入中。