相关疑难解决方法(0)

我们使用 Postgres 进行分析（星型模式）。每隔几秒钟，我们就会收到大约 500 种指标类型的报告。最简单的模式是：

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

我们的 DBA 提出了一个建议，将所有相同 5 秒的报告展平为：

timestamp   metric1     metric2     ...  metric500
78930890    90.9        20          ...  

一些开发人员反驳这种说法，称这增加了开发的巨大复杂性（批处理数据，以便一次性编写）和可维护性（仅查看表或添加字段更复杂）。

DBA 模型是此类系统中的标准做法还是仅在原始模型显然不够可扩展时的最后手段？

编辑：最终目标是为用户绘制折线图。因此，查询主要是选择几个指标，按小时/分钟折叠它们，然后选择每小时（或任何其他时间段）的最小值/最大值/平均值。

编辑：DBA 的主要论点是将行数减少 x500 次将允许更高效的索引和内存（在此优化之前，该表将包含数亿行）。然后在选择多个度量标准时，建议的架构将允许一个通过数据而不是每个度量的单独索引搜索。

编辑：500 个指标是一个“上限”，但实际上大部分时间每 5 秒只报告约 40 个指标（虽然不是相同的 40）

就像另一个问题所示，我在 3D 空间中处理了很多（> 10,000,000）个点条目。这些点定义如下：

CREATE TYPE float3d AS (
  x real,
  y real,
  z real);

如果我没记错的话，需要 3*8 字节 + 8 字节填充（MAXALIGN是 8）来存储这些点之一。有没有更好的方法来存储这种数据？在前面提到的问题中，有人指出复合类型涉及相当多的开销。

我经常做这样的空间查询：

  SELECT t1.id, t1.parent_id, (t1.location).x, (t1.location).y, (t1.location).z,
         t1.confidence, t1.radius, t1.skeleton_id, t1.user_id,
         t2.id, t2.parent_id, (t2.location).x, (t2.location).y, (t2.location).z,
         t2.confidence, t2.radius, t2.skeleton_id, t2.user_id
  FROM treenode t1
       INNER JOIN treenode t2 ON
         (   (t1.id = t2.parent_id OR t1.parent_id = t2.id)
          OR (t1.parent_id IS NULL AND t1.id = t2.id))
        WHERE (t1.LOCATION).z = 41000.0
          AND (t1.LOCATION).x > 2822.6
          AND (t1.LOCATION).x …

在另一个问题中，我了解到我应该从我的一个表中优化布局以节省空间并获得更好的性能。我这样做了，但最终得到了比以前更大的表，并且性能没有改变。当然我做了一个VACUUM ANALYZE. 怎么会？

（我看到如果我只索引单列，索引大小不会改变。）

这是我来自的表（我添加了尺寸 + 填充）：

                               Table "public.treenode"
    Column     |           Type           | Size |          Modifiers
---------------+--------------------------+------+-------------------------------
 id            | bigint                   | 8    | not null default nextval( ...
 user_id       | integer                  | 4+4  | not null
 creation_time | timestamp with time zone | 8    | not null default now()
 edition_time  | timestamp with time zone | 8    | not null default now()
 project_id    | integer                  | 4    | not null
 location      | real3d                   | 36   | …

我在 Postgres 9.3 数据库中有这个表：

我需要使用列的内容order，并limit进行排序和筛选此表。该表将按列排序first_name。

最终结果将如下图所示：

注意：对不起，如果这对你来说很简单，但我无法解决这个问题。所有邮件地址均由 www.mockaroo.com 生成。如果您的地址在此列表中，请不要怪我。

order和limit列将始终具有相同的数据。order可能是asc或desc也limit可能是任何整数值（但所有行都将是相同的值。它来自分组查询。

我的表在白天变化很大，大量数据被删除、修改和插入。

我怀疑这些表上的表和索引可能会臃肿。

我已经看到 PostgreSQL 的扩展选项可以检查这一点，但我想避免在我的数据库中创建扩展。

如何获取此信息（表/索引臃肿）而不必使用 PostgreSQL 扩展（例如：pgstattuple），仅使用本机 PostgreSQL 12 功能。

相反：在创建新表时获取所有列是否更好？

我正在开发一个新系统，而且新的要求一直在出现。最新的要求是为每个客户添加一个新的标签字段，以便更容易在新旧系统之间关联数据。新系统尚未投入生产，但已经完成了迁移过程的一些测试运行。

目前，删除表并重新运行批量加载仍然可行，但未来如何 - 当系统中有大量实时数据并且出现对新列的需求时：它对例如，要导出数据，重新创建包含所有列的表，然后再次导入数据，而不仅仅是执行 ALTER TABLE ADD 列......？

如果它有任何不同，该解决方案基于 PostgreSQL 9.5，如果它确实有所不同，那么了解哪些 DBMS 或多或少关心会很有趣。

是否在此列上创建索引会影响答案？例如，当设置了唯一约束时。

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

关键是：从 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, …

我想根据 ID 获取最多 100 行。id 是表的主键。

我编写的查询如下所示：

select * from table where id = any ($1);

其中$1被插值为 ids 数组。

使用时EXPLAIN ANALYZE我得到以下计划（解释链接）：

                                                                QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.43..44.98 rows=17 width=553) (actual time=100.048..834.209 rows=17 loops=1)
   ->  Index Scan using instagram_id_index_1000 on profiles_1000  (cost=0.43..44.98 rows=17 width=553) (actual time=100.046..834.163 rows=17 loops=1)
         Index Cond: (id = ANY ('{34491540,28977916,33241270,33609141,31043380,29364420,30247037,33311491,36267571,32886281,32366574,32569254,33038689,31089076,29416100,30455309,31570597}'::integer[]))
 Planning time: 424.512 ms
 Execution time: 834.280 ms
(5 rows)

当我实际执行它时（使用\timing），我得到的结果在 2-5 秒范围内！我真的无法接受如此糟糕的表现。EXPLAIN ANALYZE首先提供的执行时间就已经很长了。

一些上下文：
1）数据库是本地的，所以没有网络延迟
2）我查询的表是物化视图
3）我也尝试了 …

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 …

我们有一个大型查询，当客户“第一次运行它时，一大早......”

所以，我发现pg_prewarm我想使用加载到 PG 的缓冲区缓存一定数量或最近访问的行（插入、更新或删除）来自上述查询中使用的几个表。

此外，我需要确保“预热”不超过 PG 的缓存（我相信是 shared_buffers 设置，还是我错了？）为了预热单个表的最后 1000 页，我可以这样做：

SELECT pg_prewarm(
    'mytable',
    -- "pre warm" last 1000 pages
    first_block := ( 
        SELECT pg_relation_size('mytable') / current_setting('block_size')::int4 - 1000
    )
);

问题 1：这种方法有意义吗？

诀窍是 pg_prewarm 只能加载一定数量的页面，所以我需要计算“某个表的页面中有多少活动行”

-- show some settings
SELECT current_setting('block_size')::int4 AS page_size_bytes; -- 8192
SHOW shared_buffers; -- 512 MB


-- https://www.postgresql.org/docs/current/static/pgstattuple.html
--CREATE EXTENSION pgstattuple;
-- find out live row size and live rows per page
SELECT 'mytable'AS table_name, pg_size_pretty(tuple_len / tuple_count) AS live_row_size, 8192.00 / (tuple_len …

我决定使用可为空字段或 jsonb 来存储用户配置文件。最初，这将用于联系人：email和phone。我预计稍后可能会添加其他列，例如mobile和website。此外，可能还有其他不相关的字段，例如设置/首选项、保存的搜索等。

我已经决定我不想为此使用任何形式的键值存储（或任何涉及多对多关系的模式），除非有非常好的理由。

jsonb 的优点：

• 如有必要，可以为每个“列”存储多个值
• 添加新字段只需要 JS 编码和文档

jsonb 的缺点：

• 将“列”名称存储为每个“行”的字符串的开销
• Wonky 执行比较查询（我认为我的使用场景不适用）
• 不得不期待意外

还有什么要添加到这个优点/缺点列表中的吗？尽管我只想使用可为空的列，但我认为忽略 jsonb 是一种疏忽 - 这似乎是一个令人信服的选择。

在多租户只有一个DB中，使用一列来隔离客户数据，即customer_id。

是否可以在所有表​​中获取某个客户的存储大小？