相关疑难解决方法(0)

我正在处理一个使用instagram 密钥格式的项目。

TL;DR 64 位整数 ID。

它们将用于查找，我们也喜欢它们用于排序和批处理，因为它们会自然地按创建时间排序。

这些值介于 2^63 和 2^64 之间，因此（只是）太大而无法放入BIGINT.

因此，我们的存储选项似乎是numeric(20)或varchar。varchar不是那么理想，因为我们必须将它们归零才能进行排序才能工作，但是使用数字进行查找会影响性能吗？

Postgres 文档声明了以下有关仅索引扫描和覆盖索引的内容：

如果您经常运行类似的查询

SELECT y FROM tab WHERE x = 'key';

加速此类查询的传统方法是仅在 x 上创建索引。然而，索引定义为

CREATE INDEX tab_x_y ON tab(x) INCLUDE (y);

可以将这些查询作为仅索引扫描来处理，因为可以从索引中获取 y 而无需访问堆。

因为列 y 不是索引搜索键的一部分，所以它不必是索引可以处理的数据类型；它仅存储在索引中，并且不被索引机制解释。另外，如果索引是唯一索引，即

CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);

唯一性条件仅适用于 x 列，不适用于 x 和 y 的组合。（INCLUDE 子句也可以用 UNIQUE 和 PRIMARY KEY 约束编写，为设置这样的索引提供替代语法。）

问题1：如果 的数据类型y可以添加到索引中，并且没有唯一性要求，那么使用CREATE INDEX tab_x_y ON tab(x) INCLUDE (y)overCREATE INDEX tab_x_y ON tab(x, y)进行查询有什么优势SELECT y FROM tab WHERE x = 'key';？

在向索引添加非键有效负载列（尤其是宽列）时保持保守是明智的做法。如果索引元组超过索引类型允许的最大大小，数据插入将失败。在任何情况下，非键列都会复制索引表中的数据并使索引的大小膨胀，从而可能会减慢搜索速度。 …

我有一个关于我的数据库大小的简短问题。我需要在数据库中插入数据。在插入之前，需要进行一些计算。

关键是：从 50 mb 纯数据（~700,000 行），这导致 600 mb db 大小。这是12倍！我确定我在这里做错了什么。你能帮我缩小我的数据库的大小吗？数据库大小的来源是 web postgres 管理界面。

这是插入：

CREATE TYPE CUSTOMER_TYPE AS ENUM
('enum1', 'enum2', 'enum3', '...', 'enum15');       ## max lenght of enum names ~15

CREATE TABLE CUSTOMER(
   CUSTOMER_ONE    TEXT PRIMARY KEY NOT NULL,       ## max 35 char String
   ATTRIBUTE_ONE   TEXT UNIQUE,                     ## max 35 char String
   ATTRIBUTE_TWO   TEXT UNIQUE,                     ## max 51 char String
   ATTRIBUTE_THREE TEXT UNIQUE,                     ## max 52 char String
   ATTRIBUTE_FOUR  TEXT UNIQUE,                     ## max 64 char String
   ATTRIBUTE_FIFE  TEXT UNIQUE, …

varchar(5)当我在查询中使用时INSERT，这意味着表中的属性将在内存中占用5 个字节？（假设一个可打印字符占用一个字节）？