Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
3f898403
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
3f898403
编写于
2月 04, 2006
作者:
B
Bruce Momjian
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Add to TODO.detail/walcontrol.
上级
b3769066
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
58 addition
and
0 deletion
+58
-0
doc/TODO.detail/walcontrol
doc/TODO.detail/walcontrol
+58
-0
未找到文件。
doc/TODO.detail/walcontrol
浏览文件 @
3f898403
...
...
@@ -3319,3 +3319,61 @@ above, we can do it.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
From simon@2ndquadrant.com Thu Jan 5 16:56:25 2006
Return-path: <simon@2ndquadrant.com>
Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id k05LuPb02246
for <pgman@candle.pha.pa.us>; Thu, 5 Jan 2006 16:56:25 -0500 (EST)
Received: from [192.168.0.3] (unknown [84.12.184.6])
by smtp.nildram.co.uk (Postfix) with ESMTP
id A9F0F268C4E; Thu, 5 Jan 2006 21:56:18 +0000 (GMT)
Subject: Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
From: Simon Riggs <simon@2ndquadrant.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>,
Greg Stark <gsstark@mit.edu>, Rod Taylor <pg@rbt.ca>,
Qingqing Zhou <zhouqq@cs.toronto.edu>, pgsql-hackers@postgresql.org
In-Reply-To: <200601051727.k05HR5p02803@candle.pha.pa.us>
References: <200601051727.k05HR5p02803@candle.pha.pa.us>
Content-Type: text/plain
Date: Thu, 05 Jan 2006 21:56:21 +0000
Message-ID: <1136498181.21025.285.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4)
Content-Transfer-Encoding: 7bit
Status: OR
On Thu, 2006-01-05 at 12:27 -0500, Bruce Momjian wrote:
> Seems like a nice optimization.
Negative thoughts: Toast tables have a toast index on them, yes? We have
agreed that we cannot use the optimization if we have indexes on the
main table. It follows that we cannot use the optimization if we have
*any* toasted data, since that would require a pointer between two
blocks, which would not be correctly recovered following a crash. If we
log the toast table then there could be a mismatch between heap and
toast table; if we don't log the toast table there could be a mismatch
between toast table and toast index.
We can test to see if the toast table is empty when we do ALTER TABLE,
but loading operations may try to create toasted data rows.
Presumably that means we must either:
i) abort a COPY if we get a toastable value
ii) if we get a toastable value, insert the row into a new block, which
we do logging of, then also log the toast insert and the toast index
insert - i.e. some blocks we log, others not
This is still useful for many applications, IMHO, but the list of
restrictions seems to be growing. Worse, we wouldn't know that the toast
tables were empty until after we did the COPY TO for a pg_dump, so we
wouldn't be able to retrospectively add an ALTER TABLE command ahead of
the COPY.
Thoughts? Hopefully there are some flaws in my thinking here,
Best Regards, Simon Riggs
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录