Re: Killing dead index tuples before they get vacuumed

On Tue, 21 May 2002 12:48:39 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

Servus
Manfred