标签: postgresql-10

我有一列 type JSONB，其中每一行都包含一个带有对象数组的 JSON，例如：

[
    {
        "grade": "4.44/5",
        "endYear": 2011,
        "startYear": 2006,
        "userId": "defg"
    },
    {
        "grade": "9.133/10",
        "endYear": 2010,
        "startYear": 2006,
        "userId": "abcd"
    }
]

我正在尝试将这些JSONB集合扩展为行，例如：

| grade    | startYear | endYear | userId |
-------------------------------------------
| 4.44/5   |    2006   | 2011    | defg   |
| 9.133/10 |    2006   | 2010    | abcd   |
-------------------------------------------

..使用以下查询：

WITH arr AS (SELECT jsonb_array_elements(jsonbrecords) AS jsons
             FROM "table-with-jsonb"),
    lines AS (
      SELECT x.*
      FROM arr, jsonb_to_record(jsons) AS x(
                "field1" …

format我在使用下面示例中的函数正确引用表名时遇到一些问题。

CREATE OR REPLACE FUNCTION copy_table(_source_tbl regclass, _target_tbl text)
 RETURNS bool AS $func$
DECLARE query_str text; 
BEGIN
  query_str = format($fmt$ DROP TABLE IF EXISTS %1$I; CREATE TABLE %1$I AS (TABLE %s); $fmt$, _target_tbl, _source_tbl);
  EXECUTE query_str;
  RAISE NOTICE '%', query_str;
 RETURN True;
END $func$ LANGUAGE plpgsql;

我的困境是我想引用输入表名称_target_tbl作为标识符（以避免 SQL 注入）。但是，给定完整的表名称ex.test1，这会导致架构部分ex.被视为表名称的一部分，并public."ex.test1"在默认public.架构中创建表，如下所示。

我应该如何在此处正确引用/格式化标识符？

=> SELECT copy_table('ex.test', 'ex.test1');
NOTICE:  table "ex.test1" does not exist, skipping
NOTICE:   DROP TABLE IF EXISTS "ex.test1"; CREATE TABLE …

除了这几个表之外，我需要在具有不同目的和模式的数据库之间保持更新几个表。

我当前的解决方案是一个 cron 作业，它每分钟左右从一个数据库中进行选择并插入到另一个数据库中，但我想知道 PostgreSQL 版本 10 是否有更强大的解决方案。

在 Postgres 10 中我有下表：

CREATE TABLE testtable (
    id  int   PRIMARY KEY,
    qty jsonb
);
INSERT INTO testtable (id,qty)
VALUES
  ( 1, '{"2018-08-01": 10, "2018-08-11": 20, "2018-10-23": 30}' ),
  ( 2, '{"2018-08-17": 100, "2018-11-01": 200}' ),
  ( 3, '{"2018-09-03": 1, "2018-09-01": 2, "2018-10-01": 3}' );

有没有一种快速的方法，使用 SQL 返回每个 JSONB 字段的总和，以便结果为：

ID Total
1   60
2   300
3   6

我已经看到使用 UNNEST 和/或替换（/sf/ask/1868972101/）更复杂的可能性。

然而，我希望有更优雅的东西。

我有一个包含大量表（当前为 93k）的 PostgreSQL 数据库，并且我看到事务 ID 年龄威胁环绕的问题，因为对于长时间未写入的干净表，不会触发 autovacuum。

例如，我有一个表，我可以看出自“2018-09-19 10:30:43.625069+00”以来还没有被写入，这要归功于对该表的唯一插入总是设置一列updated_at（当前日期时间是“2018”） -10-04 23:58:25.545881+00')，有n_dead_tup = 0，并且有age(relfrozenxid) > 10000000。

我有autovacuum_freeze_max_age = 10000000所以这应该意味着这个表将被自动清理，但相反我看到它超过了这一点，然后表的自动清理不会被触发（它目前处于age(relfrozenxid) > 70000000并且自动清理仍然没有触发。

我目前已将自动真空设置为最大程度地激进，但这种情况仍在发生。以下是自动清理设置：

track_counts = on
autovacuum = on
autovacuum_vacuum_cost_delay = 0
autovacuum_vacuum_cost_limit = 10000
autovacuum_vacuum_scale_factor = 0
autovacuum_vacuum_threshold = 1
autovacuum_freeze_max_age = 10000000
vacuum_freeze_min_age = 1000000

（是的，我意识到autovacuum_vacuum_cost_limit这并不重要，autovacuum_vacuum_cost_delay因为0）

目前，我被迫定期手动触发这些表的真空，以防止事情失控。不过，这感觉就像是黑客攻击。

有没有办法让 autovacuum 来清理这些表，或者相当于 autovacuum 忽略这些表的原因？

预计到达时间

如果有人来这里想看我处理这个问题的脚本，这里是：

#!/bin/bash -e
while true; do
  sleep 60 #just in case …

问题症状

postmaster与尝试插入低容量行的客户端连接相关的子进程的 CPU 使用率较高（导致插入的行比使用相同行慢 25 倍）。COPY ... FROM STDIN

背景

尝试识别系统/数据库配置以缓解上述较差的插入性能。我正在使用多线程 R 脚本来处理数据并将结果插入到 PostgreSQL 数据库中。我对 R 脚本进行了分析，以隔离调用的性能瓶颈DBI::dbBind()，同时用于top监视postmaster与子 R 线程打开的连接关联的子进程（请参阅下面的代码）。在 INSERT 期间，R 子进程大部分时间处于空闲状态（大概是在等待调用返回DBI::dbBind()），而postmaster子进程在其运行大约 2-3 分钟的时间内消耗了 95-100% 的 CPU。

系统/环境：

• postgresql 版本 10.3（Fedora 包 10.3-5.fc27）
• uname -a:Linux localhost 4.16.6-202.fc27.x86-64 #1 SMP Wed May 2 00:09:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• /proc/cpuinfo： 16 个处理器 ( Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz)

• ulimit …

BRIN 索引似乎很有用，但我不确定如何在 ENUM 类型上使用。我认为这段代码会起作用：

CREATE TYPE test_enum AS ENUM ('a', 'b');
CREATE TEMPORARY TABLE my_table (
    x test_enum
);

CREATE INDEX test_index ON my_table using brin (x);
ERROR:  data type test_enum has no default operator class for access method "brin"

我是否必须从头开始创建一个新的运算符类？枚举不是已经订购了吗？

这个提交，从 2014 开始，意味着 BRIN 索引应该适用于 ENUM 类型。

尝试生成 SQL 来计算给定百分位值集的加权连续值（下面使用的 25%、50% 和 75% 级别，但解决方案应允许任意参数级别）。换句话说，想要找到下面“源”表中测试数据的 25%、50% 和 75% 累积百分位数的插值“原始”值（按“cnt”加权）。

注意： 表示采样期间cnt该值出现的次数，预期输出将对该值进行加权以得出百分位数（类似于分位数/中位数和类似的统计数据）rawrawcnt

测试数据：（表：来源）

|  site  |  dateval   |  raw  |   cnt   |
+--------+------------+-------+---------+
|   A    | 2019-01-05 |   45  |      14 |
|   A    | 2019-01-05 |   52  |     178 |
|   A    | 2019-01-05 |   45  |       9 |
|   A    | 2019-01-05 |   37  |      75 |
|   A    | 2019-01-05 |   23  |      98 |
|   A    | 2019-01-05 | …

我在应用程序中的一个特别大的表上过度使用了 CITEXT 列。我想支持其中一些，因为如何触发所需索引的查找令人困惑。

我的问题是，我可以在不遇到任何重大困难的情况下做到这一点吗？如果我更改此设置，我是否需要重建这些字段上的任何索引？

朝这个方向发展会带来空间收益吗？

这些列不需要不区分大小写的查询。

我对该表进行了基于 2 列的计数，这些计数需要一个多小时。该表有 60 列。

我正在使用 Postgres 10.6。

我主要感兴趣的是，如果索引包含已从 CITEXT 更改为 VARCHAR 的列，是否需要重建索引。

我想为人口稀少的列创建最有效的索引。我只需要相等操作，所以 HASH 索引应该是有益的。

现在我想知道为什么部分哈希索引不小于完整哈希索引：

CREATE INDEX full_hash    ON mytable USING HASH(my_id); # 256 MB
CREATE INDEX partial_hash ON mytable USING HASH(my_id) WHERE my_ID IS NOT NULL; # 256 MB

CREATE INDEX full_btree    ON mytable (my_id); # 537 MB
CREATE INDEX partial_btree ON mytable (my_id) WHERE my_ID IS NOT NULL; # 32 MB

两个哈希索引占用的空间量完全相同（如 pgHero 所示）。但是，在使用标准 BTREE 索引时，部分索引仅占用完整索引空间的 5%。

PostgreSQL 10 不支持部分 HASH 索引吗？