Re: Free space management within heap page

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Free space management within heap page
Date: 2007-01-24 07:15:53
Message-ID: 2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/23/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2007-01-24 07:37:55 Re: Piggybacking vacuum I/O
Previous Message Tom Lane 2007-01-24 07:12:49 Re: Piggybacking vacuum I/O