Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 07BD29FB4F1
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Wed, 24 Jan 2007 03:16:04 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024)
	with ESMTP id 74614-08 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Wed, 24 Jan 2007 03:15:56 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169])
	by postgresql.org (Postfix) with ESMTP id 736B39F9D4D
	for <pgsql-hackers@postgresql.org>;
	Wed, 24 Jan 2007 03:15:57 -0400 (AST)
Received: by ug-out-1314.google.com with SMTP id k3so89414ugf
	for <pgsql-hackers@postgresql.org>;
	Tue, 23 Jan 2007 23:15:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=Tpx78CJAPvY1kIb0q/MA6LG8xawQlpU7gCvg1m1BJQL4gF6vulkY3gm5uScisu0O82saY6q20Mmv6Jd/pDry9iZn2JtNYnPq7y3bVUbILml8LHBVtVbLsNNufIOO+he8KJ/IKNz9pQeRmHN13AI1m62fnWBZzELhMwreSea6AHI=
Received: by 10.78.160.2 with SMTP id i2mr317779hue.1169622953799;
	Tue, 23 Jan 2007 23:15:53 -0800 (PST)
Received: by 10.78.81.13 with HTTP; Tue, 23 Jan 2007 23:15:53 -0800 (PST)
Message-ID: <2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com>
Date: Wed, 24 Jan 2007 12:45:53 +0530
From: "Pavan Deolasee" <pavan.deolasee@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: Free space management within heap page
Cc: "Martijn van Oosterhout" <kleptog@svana.org>, pgsql-hackers@postgresql.org
In-Reply-To: <18259.1169563079@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_409_9139160.1169622953471"
References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
	<20070123084846.GC19527@svana.org>
	<2e78013d0701230103y1d587db9q6733adca0ca92ca0@mail.gmail.com>
	<18259.1169563079@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200701/1117
X-Sequence-Number: 97018

------=_Part_409_9139160.1169622953471
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> > I know it might break the ctid chain, but does that really matter ?
>
> Yes.  You can't just decide that the tuple isn't needed anymore.
> As per other followup, you could possibly shrink a known-dead tuple to
> just the header.


My apologies if this has been discussed before. I went through the earlier
discussions, but its still very fuzzy to me. I am not able to construct a
case
where a tuple is DEAD (not RECENTLY_DEAD) and still there could be
a transaction need to follow the ctid pointer chain from its parent. Can
somebody help me to construct this scenario ?


The notion of keeping linked lists etc seems like gross overdesign to me.
> Why not just compact out the free space?


That would require us to acquire vacuum-strength lock on the page. For a
very large table where the probability of two backends looking at the same
page is very low, we might still be able to do that in most of the cases.
But
compacting a page would cause lots of data movements which might be
CPU intensive. Just a thought though.

Thanks,
Pavan

-- 

EnterpriseDB     http://www.enterprisedb.com

------=_Part_409_9139160.1169622953471
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><div><span class="gmail_quote">On 1/23/07, <b class="gmail_sendername">Tom Lane</b> &lt;<a href="mailto:tgl@sss.pgh.pa.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tgl@sss.pgh.pa.us</a>&gt; wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&quot;Pavan Deolasee&quot; &lt;<a href="mailto:pavan.deolasee@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">pavan.deolasee@gmail.com</a>&gt; writes:<br>&gt; I know it might break the ctid chain, but does that really matter ?
<br><br>Yes.&nbsp;&nbsp;You can&#39;t just decide that the tuple isn&#39;t needed anymore.
<br>As per other followup, you could possibly shrink a known-dead tuple to<br>just the header.</blockquote><div><br>My apologies if this has been discussed before. I went through the earlier<br>discussions, but its still very fuzzy to me. I am not able to construct a case
<br>where a tuple is DEAD (not RECENTLY_DEAD) and still there could be<br>a transaction need to follow the ctid pointer chain from its parent. Can<br>somebody help me to construct this scenario ?<br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

The notion of keeping linked lists etc seems like gross overdesign to me.<br>Why not just compact out the free space?</blockquote><div><br>That would require us to acquire vacuum-strength lock on the page. For a<br>very large table where the probability of two backends looking at the same
<br>page is very low, we might still be able to do that in most of the cases. But<br>compacting a page would cause lots of data movements which might be<br>CPU intensive. Just a thought though. <br><br>Thanks,<br>Pavan<br>
<br></div></div>-- <br><br>
EnterpriseDB&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.enterprisedb.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.enterprisedb.com</a>


------=_Part_409_9139160.1169622953471--