相关疑难解决方法(0)

我们正在设计一个众所周知的读取量大的系统（每分钟读取数万次）。

• 有一个表names作为一种中央注册表。每行都有一个text字段representation和一个唯一的字段，key它是该字段的 MD5 哈希值representation。¹该表目前有数千万条记录，预计在应用程序的生命周期内会增长到数十亿条。
• 还有许多其他表（具有高度变化的模式和记录计数）引用该names表。这些表之一中的任何给定记录都保证有一个name_key，它在功能上是names表的外键。

_{1：顺便说一句，正如您所料，此表中的记录一旦写入便不可变。}

对于表以外的任何给定表names，最常见的查询将遵循以下模式：

SELECT list, of, fields 
FROM table 
WHERE name_key IN (md5a, md5b, md5c...);

我想优化读取性能。我怀疑我的第一站应该是最小化索引的大小（尽管我不介意在那里被证明是错误的）。

问题：和列
的最佳数据类型是什么？ 有理由使用over吗？或者？keyname_key
hex(32)bit(128)BTREEGIN

我在 Postgres 9.5 中使用新的 UPSERT 功能时遇到问题

我有一个表，用于从另一个表聚合数据。复合键由 20 列组成，其中 10 列可以为空。下面我创建了我遇到的问题的较小版本，特别是 NULL 值。

CREATE TABLE public.test_upsert (
upsert_id serial,
name character varying(32) NOT NULL,
status integer NOT NULL,
test_field text,
identifier character varying(255),
count integer,
CONSTRAINT upsert_id_pkey PRIMARY KEY (upsert_id),
CONSTRAINT test_upsert_name_status_test_field_key UNIQUE (name, status, test_field)
);

根据需要运行此查询（首先插入，然后插入只会增加计数）：

INSERT INTO test_upsert as tu(name,status,test_field,identifier, count) 
VALUES ('shaun',1,'test value','ident', 1)
ON CONFLICT (name,status,test_field) DO UPDATE set count = tu.count + 1 
where tu.name = 'shaun' AND tu.status = 1 AND tu.test_field = …

我对字符变化列有一个独特的限制，该列的长度通常约为 600，但可以达到 1000 万。

我已经阅读了B-Trees，但我无法确定索引将消耗多少磁盘空间，或者如此大的值是否会阻止索引高效运行。

具有如此大长度的字符变化列对 B 树索引的磁盘空间和时间有何影响？