Re: Free space management within heap page - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Free space management within heap page
Date
Msg-id 2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com
Whole thread Raw
In response to Re: Free space management within heap page  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Free space management within heap page  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Piggybacking vacuum I/O
Next
From: "Pavan Deolasee"
Date:
Subject: Re: Piggybacking vacuum I/O