相关疑难解决方法(0)

我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？

如果答案是“视情况而定”，那么：

• 我有一个较大的数据库（30 GiB 压缩转储大小，200 GiB 数据目录）
• 我对数据库做 ETL，每周导入接近 300 万行
• 变化最频繁的表全部继承自一个主表，主表中没有数据（数据按周分区）
• 我创建每小时汇总，并从那里创建每日、每周和每月报告

我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。

从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？

我正在使用 Postgres 9.5。我有一个记录来自多个网站的页面点击量的表格。该表包含从 2016 年 1 月 1 日到 2016 年 6 月 30 日的大约 3200 万行。

CREATE TABLE event_pg (
   timestamp_        timestamp without time zone NOT NULL,
   person_id         character(24),
   location_host     varchar(256),
   location_path     varchar(256),
   location_query    varchar(256),
   location_fragment varchar(256)
);

我正在尝试调整一个查询，该查询计算执行给定页面命中序列的人数。该查询旨在回答诸如“有多少人查看了主页，然后访问了帮助站点，然后查看了感谢页面”之类的问题？结果看起来像这样

?????????????????????????????????????????
?  home-page ? help site  ? thankyou    ?
?????????????????????????????????????????
? 10000      ? 9800       ?1500         ?
?????????????????????????????????????????

请注意数字正在减少，这是有道理的，因为查看主页的 10000 人 9800 继续访问了帮助站点，而其中 1500 人继续点击了感谢页面。

3 步序列的 SQL 使用横向连接，如下所示：

SELECT 
  sum(view_homepage) AS view_homepage,
  sum(use_help) AS use_help,
  sum(thank_you) AS thank_you
FROM ( …

我们有一个整数列，目前仅包含 0 或 1 个值。此列现在已被开发人员用于在某些情况下存储唯一的 32 位标识符，我们需要能够有效地提取包含这些标识符中的任何一个的行。

鉴于该值在 99% 的情况下是 0 或 1（我还没有数字），如何最好地索引以查询少数情况？我认为共同价值的数量将成为一个问题是否正确？

           Column           |  Type   |     Modifiers
----------------------------+---------+--------------------
 event_value                | integer | not null

此列当前没有索引。而且我不认为需要定期只选择 0 或 1 值。

该表大小合理，目前有 3000 万行并且增长很快。

我很欣赏这不是该专栏的最佳用途，但在短期内不会改变。

我注意到涉及 jsonb 列的查询的性能在测试时在 VACUUM ANALYZE 运行之间存在显着差异。分析表格后，我似乎随机得到了完全不同的执行计划。

我在这里使用 Postgres 9.6。我的测试设置如下，我将一个键“x”插入到 jsonb 列“params”中，值在 1 到 6 之间，1 是最稀有的值，6 是最常见的值。我还有一个常规的 int 列“single_param”，其中包含用于比较的相同值分布。：

CREATE TABLE test_data (
    id      serial,
    single_param    int,
    params      jsonb
);

INSERT INTO test_data
SELECT 
    generate_series(1, 1000000) AS id, 
    floor(log(random() * 9999999 + 1)) AS single_param,
    json_build_object(
        'x', floor(log(random() * 9999999 + 1))
    ) AS params;

CREATE INDEX idx_test_btree ON test_data (cast(test_data.params->>'x' AS int));
CREATE INDEX idx_test_gin ON test_data USING GIN (params);
CREATE INDEX ON test_data(id)
CREATE INDEX ON test_data(single_param)

我正在测试的查询是对结果进行分页的典型查询，我按 …

我有一个带有主表和 2 个子表的 PostgreSQL 9.0.12 数据库。我的表：

CREATE TABLE test2 (
    id serial PRIMARY KEY,
    coll character varying(15),
    ts timestamp without time zone
);
CREATE INDEX ON test2(ts);

CREATE TABLE test2_20150812 (
    CHECK ( ts >= timestamp '2015-08-12' AND ts < timestamp '2015-08-13' )
) INHERITS (test2);

CREATE TABLE test2_20150811 (
    CHECK ( ts >= timestamp '2015-08-11' AND ts < timestamp '2015-08-12' )
) INHERITS (test2);

CREATE INDEX ON test2_20150812(ts);
CREATE INDEX ON test2_20150811(ts);
VACUUM FULL ANALYZE;

我的选择查询的解释结果（数据库中没有任何行）：

EXPLAIN (ANALYZE, BUFFERS) …

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 …