Re: Killing dead index tuples before they get vacuumed - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Killing dead index tuples before they get vacuumed
Date
Msg-id 1022073493.19624.10.camel@taru.tm.ee
Whole thread Raw
In response to Re: Killing dead index tuples before they get vacuumed  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: Killing dead index tuples before they get vacuumed  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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




pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Killing dead index tuples before they get vacuumed
Next
From: Ron Snyder
Date:
Subject: Re: [GENERAL] psql -l gives bad output