Re: Killing dead index tuples before they get vacuumed

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

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.
> > (This would allow btree index entries to be up to 10K when BLCKSZ is 32K,
> > rather than being hard-limited to 8K.)
>
> 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,
> especially when the new limit is then 10k. The limit is already 32 *
> the max key size of some other db's, and even those 256 bytes are usually
> sufficient.

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'.

And we can even make it bigger if we start measuring keys in words or
dwords instead of bytes - 16k x dword = 64kb

--------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-05-22 13:30:05 Re: Redhat 7.3 time manipulation bug
Previous Message Shra 2002-05-22 13:04:03