Manfred Koizar <[EMAIL PROTECTED]> writes:
> 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?
Mmmm ... I don't think so. That would cause the tuple to actually
disappear from the perspective of the
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.
>(
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right, that's why I said that the limit would only go up to ~10K anyway;
>> btree won't take keys > 1/3 page.
> What's the point then?
Well, btree's not the only index access method we have. I'm not sure
whether gist or rtree allow
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Also, in btree haven't we had some problems with index page
> > splits when using entries large enought so that not at least
> > 3 of them fit on a page?
>
> Right, that's why I said that the limit would only go up to ~10K
Jan Wieck <[EMAIL PROTECTED]> writes:
> Also, in btree haven't we had some problems with index page
> splits when using entries large enought so that not at least
> 3 of them fit on a page?
Right, that's why I said that the limit would only go up to ~10K anyway;
btree won't take ke
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
> >> While I agree that it might be handy to save this bit for future use,
> >> I do not see any value in increasing the max key length from 8k,
>
> > I'm not sure if it ap
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
>> While I agree that it might be handy to save this bit for future use,
>> I do not see any value in increasing the max key length from 8k,
> I'm not sure if it applies here, but key length
On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD 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.
> >
> 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 3
I'm planning to tackle the problem of killing index tuples for dead rows
during normal processing (ie, before VACUUM). We've noticed repeatedly
that visits to dead heap rows consume a lot of time during indexscans
of heavily-updated tables. This problem has been discussed before,
so the general
10 matches
Mail list logo
