From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Free space management within heap page
Date: Tue, 23 Jan 2007 09:37:30 +0000
Message-ID: <45B5D75A.5040003@enterprisedb.com> (raw)
In-Reply-To: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki@enterprisedb.com, pavan.deolasee@gmail.com
Subject: Re: Free space management within heap page
In-Reply-To: <45B5D75A.5040003@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox