Re: Killing dead index tuples before they get vacuumed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Killing dead index tuples before they get vacuumed
Date: 2002-05-22 13:47:02
Message-ID: 23642.1022075222@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)tm(dot)ee> 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 for GIST indexes may
> benefit from 2x increase (14bits = 16k). IIRC limited key length is one
> reason for intarray indexes being 'lossy'.

Since there seems to be some dissension about that, I'll leave the
t_info bit unused for now, instead of absorbing it into the length
field.

Since 13 bits is sufficient for 8K, people would not see any benefit
anyway unless they use a nonstandard BLCKSZ. So I'm not that concerned
about raising it --- just wanted to throw out the idea and see if people
liked it.

In the long run it'd be possible to not store length in IndexTupleData
at all, but rely on the length from the item header, same as we do for
heap tuples. So if we ever need more bits in IndexTupleData, there's
a way out.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2002-05-22 13:51:24 Edge case problem with pg_dump
Previous Message Thomas Lockhart 2002-05-22 13:30:05 Re: Redhat 7.3 time manipulation bug