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 [email protected]
Whole thread Raw
In response to Re: Free space management within heap page  (Tom Lane <[email protected]>)
Responses Re: Free space management within heap page
List pgsql-hackers

On 1/23/07, Tom Lane <[email protected]> wrote:
"Pavan Deolasee" <[email protected]> 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