Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Tom Lane
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Manfred Koizar
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. >(

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Tom Lane
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Jan Wieck
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Tom Lane
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Jan Wieck
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Tom Lane
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

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Hannu Krosing
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. > >

Re: [HACKERS] Killing dead index tuples before they get vacuumed

2002-05-22 Thread Zeugswetter Andreas SB SD
> 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