Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 1005A9FB5A9
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Tue, 23 Jan 2007 06:35:46 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024)
	with ESMTP id 53485-02 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Tue, 23 Jan 2007 06:35:39 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from an-out-0708.google.com (an-out-0708.google.com
 [209.85.132.251])
	by postgresql.org (Postfix) with ESMTP id CE1CA9FB5A6
	for <pgsql-hackers@postgresql.org>;
	Tue, 23 Jan 2007 06:35:41 -0400 (AST)
Received: by an-out-0708.google.com with SMTP id c24so561754ana
	for <pgsql-hackers@postgresql.org>;
	Tue, 23 Jan 2007 02:35:40 -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=GTaymGQfrZTkRetqDMoYZnjj3cP1K/sCLKwVzMf+LmQnMrBaOShG/zYDjzQ45WqpQHYLr8v+SgX+XXe+5EhKH4tvPV9lNZfELuX8DLES5OwkROZ0ON0X4sZdT9qFUnzIC6xPhRegaZDdYDHTafKxjU6rEdE7WGF0lpf+YNIRgqE=
Received: by 10.78.97.7 with SMTP id u7mr238652hub.1169548539607;
	Tue, 23 Jan 2007 02:35:39 -0800 (PST)
Received: by 10.78.81.13 with HTTP; Tue, 23 Jan 2007 02:35:39 -0800 (PST)
Message-ID: <2e78013d0701230235k5c123bddu1a850c59cb5e5cb6@mail.gmail.com>
Date: Tue, 23 Jan 2007 16:05:39 +0530
From: "Pavan Deolasee" <pavan.deolasee@gmail.com>
To: "Heikki Linnakangas" <heikki@enterprisedb.com>
Subject: Re: Free space management within heap page
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <45B5D75A.5040003@enterprisedb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_172103_11519641.1169548539561"
References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
	<45B5D75A.5040003@enterprisedb.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200701/1043
X-Sequence-Number: 96944

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

On 1/23/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
>
> Pavan Deolasee wrote:
>
> > So during a sequential or index scan, if a tuple is found to be dead,
> the
> > corresponding line pointer is marked "unused" and the space is returned
> > to a
> > free list. This free list is maintained within the page. A linked-list
> can
> > be used for this purpose and the special area of the heap-page can be
> used
> > to track the fragment list. We can maintain some additional information
> > about the fragmented space such as, total_free_space, max_fragment_size,
> > num_of_fragments etc in the special area.
>
> Maintaining a list like that seems like a lot of hassle to me. Instead,
> you could just scan the line pointers looking for a dead tuple of the
> right size. We already have to scan the line pointers when inserting to
> find a free line pointer.


That's a good suggestion. Just to avoid useless scans when there is no
fragment which can accommodate the new tuple, we may have some book keeping
information in the special area though.

Thanks,
Pavan

EnterpriseDB     http://www.enterprisedb.com

------=_Part_172103_11519641.1169548539561
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">Heikki Linnakangas</b> &lt;<a href="mailto:heikki@enterprisedb.com">heikki@enterprisedb.com</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;">
Pavan Deolasee wrote:<br><br>&gt; So during a sequential or index scan, if a tuple is found to be dead, the<br>&gt; corresponding line pointer is marked &quot;unused&quot; and the space is returned<br>&gt; to a<br>&gt; free list. This free list is maintained within the page. A linked-list can
<br>&gt; be used for this purpose and the special area of the heap-page can be used<br>&gt; to track the fragment list. We can maintain some additional information<br>&gt; about the fragmented space such as, total_free_space, max_fragment_size,
<br>&gt; num_of_fragments etc in the special area.<br><br>Maintaining a list like that seems like a lot of hassle to me. Instead,<br>you could just scan the line pointers looking for a dead tuple of the<br>right size. We already have to scan the line pointers when inserting to
<br>find a free line pointer.</blockquote><div><br>That&#39;s a good suggestion. Just to avoid useless scans when there is no fragment which can accommodate the new tuple, we may have some book keeping information in the special area though.
<br>&nbsp;<br>Thanks,<br>Pavan<br><br></div></div>EnterpriseDB&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>

------=_Part_172103_11519641.1169548539561--