Emre Sevinç's questions

当我尝试将转储文件恢复到另一个（本地）PostgreSQL 服务器（在 Debian GNU/Linux 10.10 上运行）时，出现以下错误：

pg_restore: error: could not execute query: ERROR:  option "locale" not recognized

因为它确实有以下行：

CREATE DATABASE "REMOTE_DB" WITH TEMPLATE = template0 ENCODING = 'UTF8' LOCALE = 'en_GB.UTF-8';

是的，我知道PostgreSQL 12 CREATE DATABASE命令没有LOCALE选项。

我不明白的是：

• 我在本地服务器上使用的 PostgreSQL 本身的版本报告为 12.7
• pg_dump我在本地服务器上使用的版本报告为 12.7
• pg_restore我在本地服务器上使用的版本报告为 12.7
• 我使用其创建的转储的远程 PostgreSQL 数据库pg_dump是版本 12.7，而不是 13。

让我一一验证：

我的本地服务器：

$ sudo -u postgres psql -c 'select version();'
                                                     version
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.7 (Debian 12.7-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

我的本地pg_dump版本：

$ pg_dump --version
pg_dump (PostgreSQL) 12.7 (Debian 12.7-1.pgdg100+1)

我的本地pg_restore版本：

$ pg_restore --version
pg_restore (PostgreSQL) 12.7 (Debian 12.7-1.pgdg100+1)

让我们检查一下远程数据库的 PostgreSQL 版本：

$ psql --host=REMOTE_HOST_IP_ADDRESS --dbname=REMOTE_DB --username=DB_USER -c 'select version();'
Password for user DB_USER:
                                                             version
----------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.7 (Debian 12.7-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit
(1 row)

这就是我创建转储文件的方式：

$ pg_dump --verbose \
  --create \
  --clean \
  --if-exists \
  --format=custom \
  --compress=5 \
  --host=REMOTE_HOST_IP_ADDRESS --dbname=REMOTE_DB --username=DB_USER \
  --schema=public --table=TABLE_NAME\
  > db.dump

这就是我尝试在运行 PostgreSQL 12 的本地服务器上恢复它的方式：

$ sudo -u postgres \
pg_restore --verbose \
  --create \
  --clean \
  --jobs=8 \
  --format=custom \
  --dbname=postgres \
  db.dump

PostgreSQL 13已安装，但未在此本地服务器上运行：

$ systemctl status [email protected]
● [email protected] - PostgreSQL Cluster 13-main
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled-runtime; vendor preset: enabled)
   Active: failed (Result: protocol) since Thu 2021-06-24 07:59:24 UTC; 1 day 5h ago
  Process: 562 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect 13-main start (code=exited, status=1/FAILURE)

PostgreSQL 12正在运行：

$ systemctl status [email protected]
● [email protected] - PostgreSQL Cluster 12-main
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled-runtime; vendor preset: enabled)
   Active: active (running) since Thu 2021-06-24 07:59:26 UTC; 1 day 5h ago
  Process: 556 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect 12-main start (code=exited, status=0/SUCCESS)
 Main PID: 595 (postgres)
    Tasks: 9 (limit: 36863)
   Memory: 235.7M
   CGroup: /system.slice/system-postgresql.slice/[email protected]
           ├─595 /usr/lib/postgresql/12/bin/postgres -D /var/lib/postgresql/12/main -c config_file=/etc/postgresql/12/main/postgresql.conf
           ├─678 postgres: 12/main: checkpointer
           ├─679 postgres: 12/main: background writer
           ├─680 postgres: 12/main: walwriter
           ├─681 postgres: 12/main: autovacuum launcher
           ├─682 postgres: 12/main: stats collector
           ├─683 postgres: 12/main: TimescaleDB Background Worker Launcher
           ├─684 postgres: 12/main: logical replication launcher
           └─685 postgres: 12/main: TimescaleDB Background Worker Scheduler

长话短说，我的问题是：

• 为什么我LOCALE在生成的转储文件中得到这个不受支持的选项pg_dump，而 REMOTE PostgreSQL 版本以及本地pg_dump版本报告为12.7而不是 13？

我还应该检查什么？

在 'vanilla' PostgreSQL 12.7数据库中，我通常运行以下查询来了解具有 100+ 百万行的表中的估计行数：

----------------------------------------------------------
-- Return the estimated number of rows for the given table
----------------------------------------------------------
SELECT reltuples::bigint AS estimate_number_of_rows
FROM   pg_class
WHERE  oid = to_regclass('name_of_some_big_table');

这种类型的查询不适用于我们的多节点TimescaleDB安装上的分布式超表。

我检查了TimescaleDB API 参考，但找不到我要找的东西。

有没有这样一个简单的查询来快速返回分布式超表中的估计行数？

我在 Debian GNU/Linux 服务器上运行的 PostgreSQL 12.7 数据库中有一个大表（我们称之为big_table）。这台机器有8 GB的 RAM 和4 个 CPU 核心，并且主要专用于这个 PostgreSQL 服务器。

目前这big_table有大约1.03 亿行保存时间序列数据（例如，数据不更新，只插入或删除）。几乎每个月，我都会从这个表中删除大约25到3000 万行。那些被删除的行对应于一个连续的时间范围（例如“DELETE ... between 1-Mar and 30-Mar”）。这些DELETE操作需要 10 分钟到 30 分钟才能完成。这种使用模式的有效期为6个多月。

表大小约为46 GB，该表的索引加起来约为61 GB。

有一个应用程序每隔几秒就向 this 插入 10 行big_table，另一个面向用户的 Web 应用程序从这个表中读取数据以绘制一些最近的值。

每次我运行DELETE删除 25 到 30 百万行的操作时（在月底），我都会看到AUTOVACUUM启动并开始工作。

我想检查一些关于这些 AUTOVACUUM 如何在该数据库中运行以下 SQL 查询的统计信息：

SELECT relname, last_vacuum, vacuum_count, autovacuum_count, last_autovacuum, autoanalyze_count, last_autoanalyze
FROM pg_stat_user_tables 
WHERE relname = 'big_table' ;

令我惊讶的是，它给出了以下结果：

|relname     |last_vacuum|vacuum_count|autovacuum_count|last_autovacuum|autoanalyze_count|last_autoanalyze|
|------------|-----------|------------|----------------|---------------|-----------------|----------------|
|big_Table   |           |0           |0               |               |0                |                |

我试图了解以下内容：

• 为什么都是autovacuum_count和auto_analyzecount 零？
• 为什么是last_autovacuum和last_autoanalyze NULL？

不幸的是， https: //www.postgresql.org/docs/12/monitoring-stats.html 上的官方文档对我没有太大帮助。

• 会不会是AUTOVACUUM启动但无法完成的情况？ANALYZE 也类似？
• 如果是这样，根本原因可能是什么？
• 我应该检查什么来验证常规吸尘是否能达到预期的效果？