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

Andreas

Wed, 22 May 2002 12:28:59 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Killing dead index tuples before they get vacuumed
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



22 May 2002 15:18:13 +0200
Hannu Krosing <hannu@tm.ee>
Re: Killing dead index tuples before they get vacuumed
Hannu Krosing <hannu@tm.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

Wed, 22 May 2002 09:47:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Killing dead index tuples before they get vacuumed 
Tom Lane wrote:
> Hannu Krosing <hannu@tm.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.

    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?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Wed, 22 May 2002 11:35:42 -0400 (EDT)
Jan Wieck <janwieck@yahoo.com>
Re: Killing dead index tuples before they get vacuumed
Jan Wieck <janwieck@yahoo.com> 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 keys > 1/3 page.

			regards, tom lane

Wed, 22 May 2002 11:47:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Killing dead index tuples before they get vacuumed 
Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> 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 keys > 1/3 page.

    What's the point then? I mean, someone who needs more than 8K
    will outgrow 10K in no time, and those cases are  topics  for
    comp.databases.abuse.brutal ...


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Wed, 22 May 2002 13:14:17 -0400 (EDT)
Jan Wieck <janwieck@yahoo.com>
Re: Killing dead index tuples before they get vacuumed
Jan Wieck <janwieck@yahoo.com> 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 larger tuples...

			regards, tom lane

Wed, 22 May 2002 13:27:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Killing dead index tuples before they get vacuumed 