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