Re: Killing dead index tuples before they get vacuumed - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Killing dead index tuples before they get vacuumed
Date
Msg-id qiqneuc1bjrn2frmr5odhbsa645162hsje@4ax.com
Whole thread Raw
In response to Killing dead index tuples before they get vacuumed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Killing dead index tuples before they get vacuumed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 21 May 2002 12:48:39 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>4. How exactly should a killed index tuple be marked on-disk?  While there
>is one free bit available in IndexTupleData.t_info, I would prefer to use
>that bit to expand the index tuple size field to 14 bits instead of 13.
>(This would allow btree index entries to be up to 10K when BLCKSZ is 32K,
>rather than being hard-limited to 8K.)  What I am thinking of doing is
>using the LP_DELETE bit in ItemIdData.lp_flags --- this appears to be
>unused for index tuples.  (I'm not sure it's ever set for heap tuples
>either, actually, but it definitely looks free for index tuples.)

AFAICS LP_DELETE is not used at all.  The only place where something
seems to happen to it is in PageRepairFragmentation() in bufpage.c:   if ((*lp).lp_flags & LP_DELETE) /* marked for
deletion*/       (*lp).lp_flags &= ~(LP_USED | LP_DELETE); 
but there is no place where this bit is set.  There's also a macro
definition in itemid.h:
#define ItemIdDeleted(itemId) \   (((itemId)->lp_flags & LP_DELETE) != 0)
which is *always* used in this context   if (!ItemIdIsUsed(lp) || ItemIdDeleted(lp))

So it looks save to use this bit for marking dead tuples.  Wouldn't it
be even possible to simply reset LP_USED instead of setting
LP_DELETED?

If you do not use LP_DELETED I'd vote for cleaning up the source and
removing it completely.

Yet another idea: set ItemIdData.lp_len = 0 for killed index tuples.

Will this free space be used by subsequent inserts?

ServusManfred


pgsql-hackers by date:

Previous
From: "Kenneth Chan"
Date:
Subject: A more precise polygon_overlap()
Next
From: "Dann Corbit"
Date:
Subject: Re: A more precise polygon_overlap()