Re: visibility maps

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: visibility maps
Date: 2008-12-17 13:41:01
Message-ID: 27633.1229521261@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Wed, Dec 17, 2008 at 3:29 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> I don't quite understand this paragraph. If there's any DEAD tuples or
>> line-pointers, the all-visible flag can't be set.

> No, I am saying, HOT-prune removes all DEAD tuples from the page (not
> the DEAD line pointers though) and that's why you may not need two
> vacuums for the visibility bit to set because the first phase of
> vacuum would not find any DEAD tuples.

I think what you are suggesting is that we should set the visibility map
bit while dead line pointers (tombstones) still remain. If that's what
you meant it's a bad idea. It would be correct in the sense of "there
are no invisible rows here", but it's not correct in the sense of "there
is no work for vacuum to do here". In particular that would be the
wrong definition for the hoped-for future feature of index-only scans.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-12-17 13:41:40 Re: [ADMIN] shared_buffers and shmmax
Previous Message Andrew Dunstan 2008-12-17 12:53:50 Re: parallel restore vs. windows