From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Killing dead index tuples before they get vacuumed |
Date: | 2002-05-22 20:00:30 |
Message-ID: | qiqneuc1bjrn2frmr5odhbsa645162hsje@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2002-05-22 20:45:50 | Re: A more precise polygon_overlap() |
Previous Message | Kenneth Chan | 2002-05-22 19:23:35 | A more precise polygon_overlap() |