On Tue, 21 May 2002 12:48:39 -0400, Tom Lane <[EMAIL PROTECTED]>
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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Reply via email to