小编Has*_*aig的帖子

我在 PostgreSQL 9.3 数据库中有两个表： Tablelink_reply有一个which_group指向 table的外键link_group。

我想删除link_group不link_reply存在相关行的所有行。听起来很基本，但我一直在努力。

会不会像这样简单（不工作）？

DELETE FROM link_group WHERE link_reply = NULL;

我有以下表格，

CREATE TABLE users (id int PRIMARY KEY);

-- already exists with data
CREATE TABLE message ();

我如何改变messages表格，

1. 一个名为的新列sender被添加到其中
2. sender引用users表的外键在哪里

这没有用

# ALTER TABLE message ADD FOREIGN KEY (sender) REFERENCES users;
ERROR:  column "sender" referenced in foreign key constraint does not exist

这个语句也不会创建列吗？

我有一个带有 postgresql 9.3.10 后端的 Django Web 应用程序（位于 Linux 操作系统中）。我遇到了磁盘已满错误，因此即使我尝试截断表，我也会收到以下错误：

ERROR:  could not extend file "base/30137/33186048": No space left on device
HINT:  Check free disk space.

我无法轻松地向服务器添加更多磁盘空间，也无法删除此 VM 上的内容。但是，有几个表是截断的候选表，但似乎我现在也无法截断它们。

谁能给我建议我可以在这里做什么？这严重影响了我的生产服务器，我在这里有点意外的 DBA，所以完全被难住了。

我知道空间不会突然释放（除非有TRUNCATE）。但是这个在我看来很不正常。

postgresql (9.3.10) 表在删除了 70% 的记录后没有释放空间的原因是什么？

我有一张桌子叫user_sessions_session. 顾名思义，它为 Web 应用程序的每个用户存储会话数据。

它的原始尺寸是：

              Table               |  Size   | External Size 
----------------------------------+---------+---------------
 user_sessions_session            | 15 GB   | 13 GB

此后，我删除了 3 个月前的所有用户会话。这是表中的大部分行。这是 3 天前。我刚刚再次检查了表的大小，这是我看到的：

              Table               |  Size   | External Size 
----------------------------------+---------+---------------
 user_sessions_session            | 15 GB   | 13 GB

此外，select * from pg_stat_activity where query like 'autovacuum:%';显示此时没有进行吸尘。

顺便说一句，我以前在同一个会话表上遇到过同样的问题 - 这不是一次性的。

以防万一，这是我用来获取表大小的 SQL（user_sessions_session 在列表中显示为第 1）：

SELECT                                                         
   relname as "Table",
   pg_size_pretty(pg_total_relation_size(relid)) As "Size",
   pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
   FROM pg_catalog.pg_statio_user_tables …

在托管 postgresql 数据库的 Ubuntu 机器中，我在/var/lib/postgresql/9.3/main/pg_log. 显然，几个月前的日志文件也被存储了。我手动删除了一些以摆脱我的disk full错误。每周删除旧的 postgresql 日志的可靠方法是什么？我可以做些什么postgresql.conf来自动化这个过程？

目前我有以下内容postgresql.conf：

#log_truncate_on_rotation = off         # If on, an existing log file with the
                                        # same name as the new log file will be
                                        # truncated rather than appended to.
                                        # But such truncation only occurs on
                                        # time-driven rotation, not on restarts
                                        # or size-driven rotation.  Default is
                                        # off, meaning append to existing files
                                        # in all cases.
#log_rotation_age = 1d                  # …

一个多星期前，我删除了 postgresql 表中的所有行（不是通过truncate，而是使用delete from ...）。Select count (*)显示表行现在为 0。

当我现在运行查询来查询磁盘空间时，我仍然看到该表占用了空间。具体来说，所有索引仍然存在并且正在占用空间。如何摆脱它们并释放磁盘空间？其次，当我摆脱了所有行时，为什么它们仍然留在首位？

以下是表格的详细说明，以防万一：

                                      Table "public.links_photoobjectsubscription"
     Column     |           Type           |                                 Modifiers                                  
----------------+--------------------------+----------------------------------------------------------------------------
 id             | integer                  | not null default nextval('links_photoobjectsubscription_id_seq'::regclass)
 viewer_id      | integer                  | not null
 updated_at     | timestamp with time zone | not null
 seen           | boolean                  | not null
 type_of_object | character varying(15)    | not null
 which_photo_id | integer                  | 
 which_link_id  | integer                  | 
 which_group_id | integer                  | 
 which_salat_id | integer                  | 
Indexes:
    "links_photoobjectsubscription_pkey" …

背景：这里有点意外的 DBA。我有一个类似 reddit 的网站，用户可以在其中提交指向各种互联网内容的链接，然后可以在每个帖子下发表评论。这个应用程序——我们称之为链接——有两个相应的表来存储数据：link和publicreply（即每个链接的评论关联）。

问题：由于相互依赖的 FK 约束，我似乎无法从这两个表中删除记录（用于维护）。需要指导来解决这种情况。

详细信息：每个Publicreply对象都存储Link与其关联的对象的 FK 。此外，每个Link对象还保存对与其相关联的最新公开回复的引用。这会造成所有Publicreply对象都有LinkFK 的情况，反之亦然。如：

Table "public.links_link"
        Column        |           Type           |                        Modifiers                        
----------------------+--------------------------+---------------------------------------------------------
 id                   | integer                  | not null default nextval('links_link_id_seq'::regclass)
 description          | text                     | not null
 submitter_id         | integer                  | not null
 submitted_on         | timestamp with time zone | not null
 url                  | character varying(250)   | not null
 image_file           | character varying(100)   | 
 reply_count …

数据库上的 SELECT 查询（带有表 JOIN）在运行时会影响磁盘空间吗？

背景：我有一个带有 Postgresql 后端的 Django 应用程序 (9.3.10)。我的数据库驻留在磁盘空间严重不足的虚拟机中（大约还剩 400MB）。

我查询了几个表以评估要弃用哪些数据以释放磁盘空间（这些包括跨表连接）。这些分析类型的查询被捆绑在一个单一的 url 后面，并统一运行。当我点击 url 时，包含我的数据库的虚拟机在大约半分钟后空间不足。

我是一个偶然的 DBA，仍在学习绳索。谁能解释为什么我在这种情况下空间不足？在此类操作中是否创建了某种临时文件？如果需要，我将分享我的配置详细信息。

我有一个带有 postgresql 9.3 DB（托管在 Ubuntu VM 上）的 Django 应用程序，最近该 VM 磁盘空间不足（导致no space left on device我的日志中出现错误）。

我清除了设备上的空间，一切都恢复了在线。

但是现在，对于我的少数请求，我已经开始收到django.db.utils:DatabaseError带有描述的警报failed to re-find parent key in index "links_grouptraffic_time" for split pages 24582/24583。links_grouptraffic是我的数据模型之一，并且time是该数据模型中的一个属性。

有人可以解释一下这意味着什么的背景，以及解决这个问题的方法吗？提前致谢！

是否可以为 Postgresql 后端（9.3.10 版）设置临时文件创建的位置？

这是我的场景：我的 Postgresql 数据库驻留在带有 Ubuntu 14.04 操作系统的专用 VM 中。我的 VM 带有由我的基础架构提供商提供的200GB 临时高性能 SSD 存储，用于应用程序和进程的短期存储。这是它的样子：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       221G  9.9G  200G   5% /mnt

我的磁盘空间不足，必须运行一些分析查询，由于临时文件的创建，这些查询可能使我的磁盘已满。

除了采取删除日志条目以释放更多空间或temp_file_limit在 postgresql conf 中设置等措施外，我还想知道是否可以设置临时文件的位置。毕竟，我有 220GB 可用于这些场景，所以一定要好好利用它们（交换空间也在这里设置）。

由于我是一名新手 DBA，因此我可以通过一个说明性示例来说明如何进行设置。

我有一个名为“链接”的应用程序，其中 1) 用户聚集在群组中并添加其他人，2) 在上述群组中为彼此发布内容。组由links_group我的 postgresql 9.6.5 DB 中的表定义，而他们在这些中发布的回复由links_reply表定义。总体而言，DB 的性能非常好。

然而SELECT，links_reply表上的一个查询始终显示在slow_log 中。它花费的时间超过 500 毫秒，并且比我在大多数其他 postgresql 操作中遇到的速度慢约 10 倍。

我使用 Django ORM 来生成查询。这里的ORM电话：replies = Reply.objects.select_related('writer__userprofile').filter(which_group=group).order_by('-submitted_on')[:25]。本质上，这是为给定的组对象选择最新的 25 条回复。它还选择关联user和userprofile对象。

这是我的慢日志中相应 SQL 的示例：LOG: duration: 8476.309 ms 语句：

SELECT

    "links_reply"."id",             "links_reply"."text", 
    "links_reply"."which_group_id", "links_reply"."writer_id",
    "links_reply"."submitted_on",   "links_reply"."image",
    "links_reply"."device",         "links_reply"."category", 

    "auth_user"."id",               "auth_user"."username", 

    "links_userprofile"."id",       "links_userprofile"."user_id",
    "links_userprofile"."score",    "links_userprofile"."avatar" 

FROM 

    "links_reply" 
    INNER JOIN "auth_user" 
        ON ("links_reply"."writer_id" = "auth_user"."id") 
    LEFT OUTER JOIN "links_userprofile" 
        ON ("auth_user"."id" = "links_userprofile"."user_id") 
WHERE …

在上一篇博文中获得一些有见地的指导后，我将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;（等等），对吗？不想搞砸了。