相关疑难解决方法(0)

我知道如何检查 Postgres 中索引和表的大小（我使用的是 9.4 版）：

SELECT
   relname AS objectname,
   relkind AS objecttype,
   reltuples AS "#entries", pg_size_pretty(relpages::bigint*8*1024) AS size
   FROM pg_class
   WHERE relpages >= 8
   ORDER BY relpages DESC;

但这并没有显示物化视图。如何查看它们占用了多少磁盘空间？

我在 Postgres 数据库中有 4 亿行，表有 18 列：

id serial NOT NULL,
a integer,
b integer,
c integer,
d smallint,
e timestamp without time zone,
f smallint,
g timestamp without time zone,
h integer,
i timestamp without time zone,
j integer,
k character varying(32),
l integer,
m smallint,
n smallint,
o character varying(36),
p character varying(100),
q character varying(100)

列e、k和n都是 NULL，它们根本不存储任何值，此时完全没用。它们是原始设计的一部分，但从未被移除。

编辑 - 大多数其他列都是非 NULL。

问题：

1. 如何计算这对存储的影响？它是否等于列的大小 * 行数？

2. 删除这些空列会显着提高该表的性能吗？页面缓存能够容纳更多行吗？

我已经大量更新/访问了存储序列化 java 对象的表。它们在表中停留 2-3 小时（在此期间也在更新），然后被删除。表的大小约为 300MB。我发现它非常非常频繁地被 VACUUMed 并想知道改变它fillfactor是否会有所帮助？

我正在通过 Heroku 使用 Postgres 9.3。

我有一个表，“交通”，有 100 万条记录，每天都有很多插入和更新。我需要在不同的时间范围内跨该表执行 SUM 运算，这些调用最多可能需要 40 秒，我很想听听有关如何改进它的建议。

我在这张桌子上有以下索引：

CREATE INDEX idx_traffic_partner_only ON traffic (dt_created) WHERE campaign_id IS NULL AND uuid_self <> uuid_partner;

这是一个示例 SELECT 语句：

SELECT SUM("clicks") AS clicks, SUM("impressions") AS impressions
FROM "traffic"
WHERE "uuid_self" != "uuid_partner"
AND "campaign_id" is NULL
AND "dt_created" >= 'Sun, 29 Mar 2015 00:00:00 +0000'
AND "dt_created" <= 'Mon, 27 Apr 2015 23:59:59 +0000' 

这是解释分析：

Aggregate  (cost=21625.91..21625.92 rows=1 width=16) (actual time=41804.754..41804.754 rows=1 loops=1)
  ->  Index Scan using idx_traffic_partner_only on …

我们正在为生产使用准备一个 PostgreSQL 数据库，我们需要估计这个数据库的存储大小。我们是一个在数据库管理方面缺乏专业知识的开发人员团队，因此我们正在研究、阅读手册并使用我们的一般信息技术知识来实现​​这一目标。

我们有实际数据要迁移到这个数据库，并对增长有一些粗略的估计。为了这个例子，假设我们估计每年增长 50%。

关键是：进行良好尺寸估计的一般正确技术是什么？

我们根据以下规则估算存储使用量。我们需要建议的主题用粗体文本标记。非常欢迎对整个过程的反馈：

1. 估计每个表的大小
   1. 发现每一行的实际大小。
      • 对于具有固定大小的字段（如bigint、char等），我们使用文档中描述的大小
      • 对于具有动态大小的字段（如text），我们估计了字符串长度并使用了函数select pg_column_size('expected text here'::text)
      • 我们为PostgreSQL 内部使用的OID增加了 4 个字节
   2. 将每行的大小乘以估计的行数
   3. 我是否需要在这里考虑任何开销，例如行或表元数据？
2. 估计每个表索引的大小
   • 不知道如何估计，这里需要建议
3. 估计事务日志的大小
   • 不知道如何估计，这里需要建议
4. 估计备份的大小（完整和增量）
   • 不知道如何估计，这里需要建议

5. 对实际最小尺寸的所有估计求和

6. 对 1 年后的最小规模的估计值 1、2 和 4 的总和应用 1.5 倍（增长 50%）的系数

7. 应用 1.2 ~ 1.4（多 20% 到 40%）的总体系数来估计 5 和 6 以获得良好的安全裕度

我知道规则变得相当广泛。让我知道是否需要示例以更好地理解。

我正在尝试为 Postgres 9.4 中的大型（1.2TB）静态表创建部分索引。

我的数据是完全静态的，所以我可以插入所有数据，然后创建所有索引。

在这个 1.2TB 的表中，我有一个名为的列run_id，可以清晰地划分数据。通过创建涵盖一系列run_ids 的索引，我们获得了出色的性能。下面是一个例子：

CREATE INDEX perception_run_frame_idx_run_266_thru_270
ON run.perception
(run_id, frame)
WHERE run_id >= 266 AND run_id <= 270;

这些部分索引为我们提供了所需的查询速度。不幸的是，每个部分索引的创建大约需要 70 分钟。

看起来我们的 CPU 有限（top进程显示为 100%）。
我可以做些什么来加快部分索引的创建？

系统规格：

• 18核至强
• 192GB 内存
• RAID 中的 12 个 SSD
• 自动吸尘器关闭
• 维护工作内存：64GB（太高？）

表规格：

• 大小：1.26 TB
• 行数：105.37亿
• 典型的索引大小：3.2GB（有 ~.5GB 的差异）

表定义：

CREATE TABLE run.perception(
id bigint NOT NULL,
run_id bigint NOT NULL,
frame bigint NOT NULL,
by character varying(45) NOT NULL,
by_anyone bigint NOT …

这个答案促使我再次思考我的下表，但我仍然不确定如何存储来自数据分析的变量/结果以便在后处理中快速选择。如果存储，我认为它使用部分索引（B 树）做得很好，因为在我这里描述的应用程序中只需要一个数据子集。假设您有三个标准正交表：measurement、events和headers，其中都有一些静态（以字节为单位的事件大小等）列，但想知道从数据分析中存储一些数字是否有益。

没有名称的表模式测量示例：

SERIAL                     | NOT NULL
INTEGER                    | NOT NULL
INTEGER                    | NOT NULL
TIMESTAMP WITH TIME ZONE   | DEFAULT CURRENT_TIMESTAMP

由于我需要统计数据，我担心通过 INTEGER 字段增加架构大小。我不想将很少使用的变量存储在主表中。我不希望我的索引没有像PostgreSQL Up & Running和这篇文章中描述的那样被使用，为什么我的索引没有被索引？

可能的来源

• Gordon Linoff和他的博客在这里

什么时候应该将静态/动态统计信息存储在表中？PostgreSQL 的部分索引中如何高效地存储静态/动态统计信息？

我在以下查询中使用 Postgres：

select count(*) from image;

此表上的主键是非递增的；它是存储在表中的图像的唯一序列号。我们的应用程序经常尝试摄取已经记录在数据库中的图像，因此主键/序列号确保它们只记录一次。

现在我们想知道是否应该使用递增的主键。我们在数据库中有 1,259,369 张图像，运行计数查询大约需要 7 分钟。

我们的应用程序永远不会从该表中删除图像 - 因此递增的主键将允许我们检查最后一个 ID 的值，该值等于表中的行数。

我正在进入我的神秘查询的下一个级别。看起来在一个存在的内部有一个子选择，但在同一个表上。我认为这可能可以通过INNER JOIN更高的方式简化。

使用 PostgreSQL 9.4.2。
表定义 ( /d+)：https : //gist.github.com/neezer/879f5d3649ca1903c6f3
基数：

billing_pricequote: 1,462,625 行
billing_pricequotestatus: 3,331,657 行
billing_lineitem: 43,687,855 行

这是原始查询，不建议对里面的子EXISTS查询进行修改：

SELECT i.quote_id, i.acct_id AS account_id, SUM(i.delta_amount) AS amt
FROM billing_lineitem i
INNER JOIN billing_pricequote pq ON i.quote_id = pq.id
WHERE pq.date_applied AT TIME ZONE 'PST' BETWEEN '2016-02-02T00:00:00'::timestamp
                                AND '2016-03-03T22:27:41.734102-08:00'::timestamptz
AND EXISTS(
  SELECT s1.quote_id
  FROM billing_pricequotestatus s1
  INNER JOIN (
    SELECT DISTINCT ON (quote_id) quote_id, MAX(created_at) AS max_created_at …

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';？

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