Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 4D2A39FB57B for ; Tue, 23 Jan 2007 05:37:46 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 12767-03 for ; Tue, 23 Jan 2007 05:37:43 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by postgresql.org (Postfix) with ESMTP id 482DD9FB298 for ; Tue, 23 Jan 2007 05:37:43 -0400 (AST) Received: by nf-out-0910.google.com with SMTP id x4so168166nfb for ; Tue, 23 Jan 2007 01:37:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=oCGd2FwPp38qpXRBaqkh4Emx82LQrrtA8sJxV2NgIUDNTB0ot8Cfxzv+yj70jEzZeAz8uN0KMqtrmZ8ZuzHSE5plDAoYafwcbKozx5oWf/VjMcBeZsP0hAA7yZlJvqnktLRaEdbMvxiowK2er/jSk5WTxwjYwKJHaB20JyuWnEY= Received: by 10.49.20.15 with SMTP id x15mr689093nfi.1169545061257; Tue, 23 Jan 2007 01:37:41 -0800 (PST) Received: from ?192.168.1.34? ( [81.107.201.197]) by mx.google.com with ESMTP id l32sm1835874nfa.2007.01.23.01.37.39; Tue, 23 Jan 2007 01:37:40 -0800 (PST) Message-ID: <45B5D75A.5040003@enterprisedb.com> Date: Tue, 23 Jan 2007 09:37:30 +0000 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Pavan Deolasee CC: pgsql-hackers@postgresql.org Subject: Re: Free space management within heap page References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com> In-Reply-To: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/1039 X-Sequence-Number: 96940 Pavan Deolasee wrote: > I am thinking that maintaining fragmented free space within a heap page > might be a good idea. It would help us to reuse the free space ASAP without > waiting for a vacuum run on the page. This in turn will lead to lesser heap > bloats and also increase the probability of placing updated tuple in the > same heap page as the original one. Agreed. > 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com