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
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 |