小编Gee*_*ock的帖子

这是一个关于 Postgres (v10) 的内部工作原理和性能的问题。

给定一个表 ，在和列github_repos上具有多列唯一索引，下面的两个批量更新插入操作之间是否存在任何性能差异（或其他需要注意的问题）？不同之处在于，在第一个查询中，和列包含在 UPDATE 中，而在第二个查询中则不包含。由于 UPDATE 在冲突时运行，因此和的更新值将与旧值相同，但这些列包含在 UPDATE 中，因为我正在使用的底层库就是这样设计的。我想知道按原样使用是否安全，或者我是否应该在更新中明确排除这些列。org_idgithub_idorg_idgithub_idorg_idgithub_id

查询#1：

INSERT INTO "github_repos" ("org_id","github_id","name")
VALUES (1,1,'foo')
ON CONFLICT (org_id, github_id)
DO UPDATE SET "org_id"=EXCLUDED."org_id","github_id"=EXCLUDED."github_id","name"=EXCLUDED."name"
RETURNING "id"

查询#2：

INSERT INTO "github_repos" ("org_id","github_id","name")
VALUES (1,1,'foo')
ON CONFLICT (org_id, github_id)
DO UPDATE SET "name"=EXCLUDED."name"
RETURNING "id"

github_repos桌子：

      Column       |       Type        | Collation | Nullable 
-------------------+-------------------+-----------+----------+
 id                | bigint            |           | not null |
 org_id            | bigint            |           | not null | …

Postgres 版本

使用 PostgreSQL 10.3。

表定义

CREATE TABLE tickets (
  id bigserial primary key,
  state character varying,
  closed timestamp
);

CREATE INDEX  "state_index" ON "tickets" ("state")
  WHERE ((state)::text = 'open'::text));

基数

该表包含 1027616 行，其中 51533 行具有state = 'open'和closed IS NULL或 5%。

条件为 on 的查询state按预期使用索引扫描执行良好：

explain analyze select * from tickets where state = 'open';

Index Scan using state_index on tickets  (cost=0.29..16093.57 rows=36599 width=212) (actual time=0.025..22.875 rows=37346 loops=1)
Planning time: 0.212 ms
Execution time: 25.697 …