相关疑难解决方法(0)

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

我有一张桌子占用了我们服务器上接近 90% 的高清空间。我决定删除几列以释放空间。但我需要将空间归还给操作系统。但是，问题是我不确定如果我运行 VACUUM FULL 并且没有足够的可用空间来制作表的副本会发生什么。

我知道不应使用 VACUUM FULL，但我认为这是这种情况下的最佳选择。

任何想法，将不胜感激。

我正在使用 PostgreSQL 9.0.6

表中的每一行都有一个系统列 ctid，其类型tid表示该行的物理位置：

create table t(id serial);
insert into t default values;
insert into t default values;

Run Code Online (Sandbox Code Playgroud)

select ctid
     , id
from t;

Run Code Online (Sandbox Code Playgroud)

ctid | ID
:---- | -：
(0,1) | 1
(0,2) | 2

dbfiddle在这里

从ctid最合适的类型（例如integer，bigint或numeric(1000,0)）中获取页码的最佳方法是什么？

在我能想到的唯一的办法是非常难看。

我已将数据导入新数据库（大约 600m 行时间戳、整数、双精度）。然后我创建了一些索引并试图改变一些列（有一些空间不足的问题），数据库被清空了。

现在 pgAdmin III 告诉我“临时文件的大小”是 50G~+。

1. 这些临时文件是什么？这些像 SQL Server 事务日志吗？
2. 我怎样才能摆脱它们，似乎数据库比它应该大得多（数据库的总大小为 91 GB）

在Windows 2012 服务器上使用Posgres 9.4.1 。

数据库统计选项卡的屏幕截图：

我在 Postgres 9.1 数据库中有两个表 ( table1, table2)。两者都有 oid 类型。每张表100万条记录。而pg_largeobject表的大小约为40GB。我从每个表中删除了 90 万条记录，并执行了以下命令。

vacuum full analyze table1;
vacuum full analyze table2;

pg_largeobject表大小仍然没有变化（启用自动真空）

我也需要执行上面的命令来pg_largeobject表吗？会影响什么吗？

我在 PostgreSQL 数据库中有一个大量使用的表（大约有 500 万行），我想在其中删除一列并回收该列使用的空间。

文档建议进行表重写ALTER TABLE以强制返回空间，但这在使用表时运行并不安全，并且会导致停机。是否有任何不需要停机的实用选项？我试图运行该pgcompact工具，但这并没有改变任何东西。

VACUUM ANALYZE VERBOSE在对一些较大的表进行重大DELETE/INSERT更改后，我们会在它们上运行“手册” 。这似乎没有问题，尽管有时表的VACUUM工作会运行数小时（有关类似问题和推理，请参阅此帖子）。

在进行更多研究后，我发现即使在运行VACUUM. 例如，以下是此响应中查询生成的一些统计信息。

-[ RECORD 50 ]--+---------------------------
relname         | example_a
last_vacuum     | 2014-09-23 01:43
last_autovacuum | 2014-08-01 01:19
n_tup           |    199,169,568
dead_tup        |    111,048,906
av_threshold    |     39,833,964
expect_av       | *
-[ RECORD 51 ]--+---------------------------
relname         | example_b
last_vacuum     | 2014-09-23 01:48
last_autovacuum | 2014-08-30 12:40
n_tup           |    216,596,624
dead_tup        |    117,224,220
av_threshold    |     43,319,375
expect_av       | *
-[ RECORD 52 ]--+---------------------------
relname         | example_c
last_vacuum     | …

我在亚马逊上有生产和暂存 RDS 实例，暂存数据是生产的直接副本，因此两个实例都有重复的数据。

做一个EXPLAIN ANALYZE SELECT * from my_table WHERE my_col=true;结果是：

Seq Scan on my_table (cost=0.00..142,775.73 rows=1 width=1,436) (actual time=18,170.294..18,170.294 rows=0 loops=1) Filter: my_col Rows Removed by Filter: 360275

在生产中，它是：

Seq Scan on my_table (cost=0.00..62,145.88 rows=1 width=1,450) (actual time=282.487..282.487 rows=0 loops=1) Filter: my_col Rows Removed by Filter: 366442

跑步时 select pg_total_relation_size('my_table'::regclass);

我发现舞台的大小几乎是制作的两倍。从我读过的内容来看，我看到 postgresql 的 MVCC 对此负责，因为它保留了多个版本的行。我手动运行VACUUM FULL，然后看到 staging 的大小已经减少了 2/3。现在运行相同的解释分析显示：

Seq Scan on my_table  (cost=0.00..56094.75 rows=1 width=1436) (actual time=1987.340..1987.340 rows=0 loops=1) Filter: my_col Rows Removed by …

我正在运行一个命令来在一个相当大的表（大约 3.15 亿行）上创建一个新列。这使用了比我预期更多的磁盘空间，它已经完全填满了我的 SAN。命令失败ERROR: could not extend file "pg_tblspc/14342 etc.": No space left on device

我的问题是，当命令像这样失败时，命令的结果不会立即被丢弃吗？为什么当没有对表进行实际更改时，表空间仍然已满？

最后，当 postgres 不允许我执行任何其他命令（例如 VACUUM）时，再次释放空间的最佳方法是什么？

我有一个表，其中包含需要定期运行的任务列表：

applaudience=> \d+ maintenance_task
                                                                       Table "public.maintenance_task"
               Column               |           Type           | Collation | Nullable |                   Default                    | Storage  | Stats target | Description
------------------------------------+--------------------------+-----------+----------+----------------------------------------------+----------+--------------+-------------
 id                                 | integer                  |           | not null | nextval('maintenance_task_id_seq'::regclass) | plain    |              |
 nid                                | citext                   |           | not null |                                              | extended |              |
 execution_interval                 | interval                 |           | not null |                                              | plain    |              |
 last_attempted_at                  | timestamp with time zone |           |          | now()                                        | plain    |              |
 last_maintenance_task_execution_id | integer                  |           |          | …

我尝试为我的数据创建报告，但在大表上真的很慢。

表结构为：

CREATE TABLE posts
(
  id serial NOT NULL,
  project_id integer,
  moderation character varying(255),
  keyword_id integer,
  author_id integer,
  created_at timestamp without time zone,
  updated_at timestamp without time zone,
  server_id character varying(255),
  social_creation_time integer,
  social_id character varying(255),
  network character varying(255),
  mood character varying(255) DEFAULT NULL::character varying,
  url text,
  source_id integer,
  location character varying(255),
  subject_id integer,
  conversation_id integer,
  CONSTRAINT posts_pkey PRIMARY KEY (id)
);

CREATE INDEX index_posts_on_author_id ON posts (author_id);
CREATE INDEX index_posts_on_keyword_id ON posts (keyword_id);
CREATE INDEX index_posts_on_project_id_and_network_and_social_id 
    ON posts …

由于频繁的新记录和更新记录导致索引和存储碎片，我面临性能下降和存储使用量增加的问题。

VACUUM 没有多大帮助。

不幸的是，CLUSTER 不是一个选项，因为它会导致停机并且 pg_repack 不适用于 AWS RDS。

我正在寻找 CLUSTER 的 hacky 替代品。在我的本地测试中似乎可以正常工作的一个是：

begin;

create temp table tmp_target as select * from target;

delete from target;
insert into target select * from tmp_target order by field1 asc, field2 desc;

drop table tmp_target;

commit;

ctid看起来的顺序是正确的：

select ctid, field1, field2 from target order by ctid;

问题是：这看起来好吗？是否会锁定target表以SELECT查找导致应用程序停机的查询？有没有办法列出事务中涉及的锁？

与集群命令锁定只读查询相关的副本

在上一篇博文中获得一些有见地的指导后，我将VACUUM FULL在 4 个 PostgreSQL 9.3.10 表上运行。表尺寸为：

1) links_publicreply: ~30M 行，9 列，3 个索引（类型：int、timestamp、char、bool）

2) links_reply: ~25M 行、8 列、6 个索引（类型：int、text、timestamp、char）

3) links_link: ~8M 行, 14 列, 3 个索引 (类型: int, text, dbl precision, timestamp, char bool)

4) links_user_sessions: ~2M 行、7 列、4 个索引（类型：int、text、timestamp、inet）

这是我第一次尝试回收磁盘空间。它是本地社交网站的繁忙服务器。没有时间实际上是“停机时间”。但最不忙的是大约凌晨 4:00，因此我将使用该窗口。

就经验而言，你们能否对我指出的 4 个表的 VACUUM FULL 需要多长时间形成任何意见？我想在网站上发布一条“维护中直到 xx:xx:xx”的消息。我知道没有人可以确定，但这是否足以让您形成大致的意见？

其次，为了让我们在同一页面上，我将在 psql 上运行的命令很简单VACUUM (FULL, VERBOSE, ANALYZE) link_publicreply;（等等），对吗？不想搞砸了。